Linköpings universitetSE–581 83 Linköping

+46 13 28 10 00 , www.liu.se

Linköping University | Department of Computer scienceMaster thesis, 30 ECTS | Datateknik

2017 | LIU-IDA/LITH-EX-A--17/057--SE

Security in low power wire-less networks– Evaluating and mitigating routing attacks in a reactive,on demand ad-hoc routing protocol

Säkerheten i trådlösa lågenerginätverk– Utvärdering och begränsning av routing attacker i ett reaktivtad-hoc routing protokoll

Tony FredrikssonNiklas Ljungberg

Supervisor : Marcus BendtsenExaminer : Nahid Shahmehri

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 årfrån publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår.Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstakakopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och förundervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva dettatillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. Föratt garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sättsamt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende elleregenart. För ytterligare information om Linköping University Electronic Press se förlagetshemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement– for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone toread, to download, or to print out single copies for his/hers own use and to use it unchangedfor non-commercial research and educational purpose. Subsequent transfers of copyrightcannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measuresto assure authenticity, security and accessibility. According to intellectual property law theauthor has the right to be mentioned when his/her work is accessed as described above andto be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of documentintegrity, please refer to its www home page: http://www.ep.liu.se/.

c© Tony FredrikssonNiklas Ljungberg

Abstract

Using low energy devices to communicate over the air presentsmany challenges to reach security as resources in the worldof Internet Of Things (IoT) are limited. Any extra overheadof computing or radio transmissions that extra security mightadd affects cost of both increased computing time and energyconsumption which are all scarce resources in IoT. This thesisdetails the current state of security mechanisms built intothe commercially available protocol stacks Zigbee, Z-wave, andBluetooth Low Energy, and collects implemented and proposedsolutions to common ways of attacking systems built on theseprotocol stacks. Attacks evaluated are denial of service/sleep,man-in-the-middle, replay, eavesdropping, and in mesh networks,sinkhole, black hole, selective forwarding, sybil, wormhole, andhello flood. An intrusion detection system is proposed to detectsinkhole, selective forwarding, and sybil attacks in the routingprotocol present in the communication stack Rime implementedin the operating system Contiki. The Sinkhole and Selectiveforwarding mitigation works close to perfection in larger losslessnetworks but suffers an increase in false positives in lossyenvironments. The Sybil Detection is based on Received SignalStrength and strengthens the blacklist used in the sinkhole andselective forwarding detection, as a node changing its ID toavoid the blacklist will be detected as in the same geographicalposition as the blacklisted node.

Acknowledgments

We would like to thank Linköping University for providing us with the necessary tools toconduct out research including our supervisor Markus Bendtsen and examiner Nahid Shah-mehri. To Cybercom Linköping we owe a huge thank you for giving us office space, feedback,breakfast and great discussions. Last but not least we would like to thank Elin Larsson andLisa Nilsson for supporting throughout the thesis.

iv

Contents

Abstract iii

Acknowledgments iv

Contents v

List of Figures vii

List of Tables ix

List of Abbreviations x

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Theory 42.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Network Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.7 Z-Wave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.8 Intrusion Detection Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.9 Contiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 Method 393.1 Literature study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2 Intrusion Detection System in practice . . . . . . . . . . . . . . . . . . . . . . . . 403.3 Experiment setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4 Results 544.1 Sinkhole and Selective forwarding detection and prevention results . . . . . . . 544.2 Sybil detection results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5 Discussion 705.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.2 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.3 The work in a wider context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6 Conclusion 79

v

Bibliography 80

vi

List of Figures

2.1 The three common network topologies . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Example of a ZigBee mesh network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 MITM attack concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Sinkhole bidirectional example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Wormhole attack example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.6 Sybil attack example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.7 BLE4.0 frame format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.8 BLE legacy pairing methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.9 BLE Secure Connections Just Works and Numerical Comparison. . . . . . . . . . . 182.10 BLE General authenticated message . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.11 ZigBee stack network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.12 ZigBee frame setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.13 Z-Wave stack network model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.14 Z-Wave frame setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.15 Rime communication primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.16 Example of two applications using rime . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.1 Architecture of the IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.2 Hidden node problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.3 IDS state machine of incoming packages . . . . . . . . . . . . . . . . . . . . . . . . . 463.4 IDS state machine of outgoing packages . . . . . . . . . . . . . . . . . . . . . . . . . 473.5 Distribution of data points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.6 Distribution of data points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.7 RSSI-estimation error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.8 Error in estimation of standard deviations . . . . . . . . . . . . . . . . . . . . . . . . 493.9 Common distribution of signal ratios . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.10 Setup of the sybil Impersonator environment . . . . . . . . . . . . . . . . . . . . . . 503.11 RSSI-distribution before attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.12 RSSI-distribution during attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.13 Simulated network setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.1 Sinkhole detection result graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.2 Selective Forwarding detection result graphs . . . . . . . . . . . . . . . . . . . . . . 604.3 Sinkhole and selective forwarding detection with prevention enabled result graphs 644.4 Distribution of 38000 RSSI data points . . . . . . . . . . . . . . . . . . . . . . . . . . 654.5 Sybil reports/message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.6 Setup for impersonation attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.7 Deviations during sybil Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.8 Sybil node impersonator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.9 Sybil node unsuccessful impersonator . . . . . . . . . . . . . . . . . . . . . . . . . . 674.10 False positive sybil environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.11 False positive sybil proximity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

vii

4.12 Proximity reports during a sybil attack . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.1 Example of overlapping RSSI-areas . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

viii

List of Tables

2.1 Voting attack timing windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2 Bluetooth PHYs, modulation, coding and data rate. . . . . . . . . . . . . . . . . . . 162.3 Bluetooth security conclusion table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4 ZigBee difference overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5 ZigBee security conclusion table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.6 Z-Wave security conclusion table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1 Example message exchange with and without malicious node. . . . . . . . . . . . . 44

4.1 Sinkhole detection without IDS prevention, lossless . . . . . . . . . . . . . . . . . . 554.2 Sinkhole true and false positives, without IDS prevention, lossless . . . . . . . . . . 554.3 Payload delivery ratio without IDS prevention, lossy . . . . . . . . . . . . . . . . . 564.4 Sinkhole detection without IDS prevention, lossless . . . . . . . . . . . . . . . . . . 564.5 Sinkhole true and false positives, without IDS prevention, lossy . . . . . . . . . . . 564.6 Payload delivery ratio, sinkhole attack, without IDS prevention, lossy . . . . . . . . 574.7 Selective Forwarding detection without IDS prevention, lossless . . . . . . . . . . . 584.8 Selective Forwarding true and false positives, without IDS prevention, lossless . . 584.9 Payload delivery ratio without IDS prevention, lossless . . . . . . . . . . . . . . . . 584.10 Selective Forwarding detection without IDS prevention, lossy . . . . . . . . . . . . 594.11 Selective Forwarding true and false positives, without IDS prevention, lossy . . . . 594.12 Payload delivery ratio without IDS prevention, lossy . . . . . . . . . . . . . . . . . 594.13 Sinkhole detection with IDS prevention, lossless . . . . . . . . . . . . . . . . . . . . 614.14 Sinkhole true and false positives, with IDS prevention, lossy . . . . . . . . . . . . . 614.15 Selective Forwarding detection with IDS prevention, lossless . . . . . . . . . . . . . 614.16 Selective Forwarding true and false positives, with IDS prevention, lossless . . . . 624.17 Payload delivery ratio with IDS prevention, lossless . . . . . . . . . . . . . . . . . . 624.18 Route flush commands, lossless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.19 Sinkhole detection with IDS prevention, lossless . . . . . . . . . . . . . . . . . . . . 624.20 Sinkhole true and false positives, with IDS prevention, lossy . . . . . . . . . . . . . 634.21 Selective Forwarding detection with IDS prevention, lossy . . . . . . . . . . . . . . 634.22 Selective Forwarding true and false positives, with IDS prevention, lossless . . . . 634.23 Payload delivery ratio with IDS prevention, lossy . . . . . . . . . . . . . . . . . . . 634.24 Route flush commands, lossy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.1 Sinkhole true detection comparison with SVELTE, lossless . . . . . . . . . . . . . . 715.2 Selective Forwarding true detection comparison with SVELTE, lossless . . . . . . . 72

ix

List of Abbreviations

ABC Anonymous Broadcast

AES Advanced Encryption Standard

AODV Ad-Hoc On Demand Distance Vector Routing

APS Application Support Layer

BC Identified Broadcast

CRC Cyclic Redundancy Check

CSMA Carrier Sense Multiple Access

CSRK Connection Signature Resolving Key

DH Diffie Hellman

DNS Dynamic Name Service

DODAG Destination Oriented Directed Acyclic Graph

DOS Denial of Service

DOSL Denial of Sleep

DSK Device Specific Key

DSR Dynamic Source Routing

ECC Elliptic Curve Cryptography

ECDH Elliptic Curve Diffie Hellman

IDS Intrusion Detection System

IoT Internet of Things

IRK Identity Resolvement Key

IV Initialization Vector

MAC Media Access Control

MAC Message Authentication Code

MH Multihop

MIC Message Integrity Code

NF Netflood

x

OS Operating System

PAN Pre-Agreed Nonce

PHY Physical layer

PKC Public Key Cryptography

RERR Route Error

RMH Reliable Multihop

RPA Resolvable Private Addressing

RREP Route Reply

RREQ Route Request

RSSI Received Signal Strength Indicator

RUC Reliable Unicast

SIG Bluetooth Special Interest Group

STUC Stubborn Unicast

TC Trust Center

TK Temporary Key

TTL Time To Live

UC Unicast

UDGM Unit Disk Graph Medium

WLAN Wireless Local Area Network

WPAN Wireless Personal Area Network

WSN Wireless Sensor Network

xi

1 Introduction

1.1 Motivation

Devices in the Internet of Things (IoT) have lately repeatedly made headlines due to securitybreaches where private information is leaked or devices being taken over and included intobot networks. For instance teddy bears equipped with microphones and speakers, intendedfor far away parents to talk to their children, could be hacked to say whatever the attackerwished or any audio that passes through it could be intercepted and downloaded. Babymonitors have also been reported to be hacked, sending video and audio from the source orplaying messages sent by the attacker [64]. There are large botnets created by worms suchas Hajime and Mirai that take access over IoT-devices using default login details and bruteforces their way to control of each device [21].

There are many reasons security has been dismissed in the IoT. Time to market being oneof them, as implementing security takes time which allows a competing company beat themto the market. Time is money and security can be seen as adding no value to the actualproduct, only overhead. Security also takes space both in transmission overhead, but alsovaluable space due to more lines of code creating larger files after compilation on hardwareconstrained devices, meaning a secure product might require a higher price tag which canmake it harder to sell than a the same product without security as it will have both a cheaperdevelopment cost and a cheaper hardware cost [62].

Before choosing which technology and protocol to use in a device for any application thesecurity question requires attention as some protocols do not provide access to the securitythat is deemed necessary while others have it as an opt-in feature which the developer mustbe aware of when creating secure applications.[22] To ease the process of finding out whatsecurity can be expected from the different protocols this report has been produced. It isuseful for realizing the potential security flaws of a system already in production or giveinsight about what to consider during the development cycle.

There are many scenarios where an intrusion detection system (IDS) is necessary to ensurethe function of systems critical to peoples health or buildings. Imagine a scenario where afactory has its smoke detectors set up in a wireless multihop network that is supposed toautomatically alert the fire department when smoke is detected. If a malicious attacker getsa hold of just one node it can in the worst case send out messages that will make all networktraffic pass through it, creating congestion, and it might even drop all the packages that are

1

1.2. Aim

supposed to reach a node with the ability to contact the fire department. During the day, thedelay in getting the fire department to the scene might result in heavier structure damage anddeath of employees, or during the night the alarm might never come or come too late whichmight result in the entire factory burning to the ground.

1.2 Aim

The aim of this thesis is to produce a matrix for each of the three IoT-networking protocolsZigbee, Z-Wave and Bluetooth Low Energy in regards to common attacks and their resis-tance to them. This is intended to increase awareness of security issues and create a basefor developing parties to create secure devices. Information about security is scattered allover multiple specifications, scientific reports and videos of talks from security conferencesall over the world. This thesis aims to collect key information and gathering it in one placeto reduce time needed to get started on choosing technology and beginning to implementit. Implementing the sinkhole, selective forwarding, and sybil detection aims to create anunderstanding of the feasibility and problems when implementing security on those lowperformance devices and show how fragile ad hoc mesh networking is at its core withoutsecurity.

The following questions will be answered by the research conducted in this thesis:

1. What current main security features is implemented in the low power wireless networkprotocols Bluetooth low energy, ZigBee and Z-Wave, and what attacks do they prevent?

2. What solutions exists to detect and prevent routing attacks in ad-hoc on demand rout-ing protocol networks suited for constrained IoT devices?

3. How can a distributed, lightweight, intrusion detection system for low power wirelessnetwork protocols be implemented to detect and prevent Sinkhole, Selective Forward-ing and Sybil attacks on a network?

1.3 Delimitations

The delimitations made for the first part of the report was:

• Only low energy, wireless network protocols was to be investigated.

• The research was done on information available through research libraries on the inter-net which Linköpings university gave access to.

• The research was only concluded on three of the commercially available network pro-tocol stacks, namely Bluetooth low energy, ZigBee and Z-Wave.

• The attacks evaluated for each protocol stack was man in the middle (MITM), encryp-tion key extraction/eavesdropping, replay/playback attack, denial of service, denial ofsleep, selective forwarding attack, sinkhole attack, wormhole attack, hello flood attack.

For the second part of the report that includes the implementation of an IDS, the delimi-tations were:

• The implementation of the IDS was done in an open source protocol stack which wasnot one of the protocol stacks evaluated in part one of the report.

• The evaluation of the IDS was limited to simulation in software only, i.e. no hardwarewas used to test the solution in a real world environment.

2

1.3. Delimitations

• The protocol to evaluate was only a variant of the reactive AODV, ad-hoc on demanddistance vector, routing protocol.

• The network environment the IDS was evaluated on was static, i.e. no mobility of thenodes.

• The hardware resources on the nodes are limited in terms of processing power, memoryand wireless bandwidth.

• The attackers are presumed to be included in the network, and no end-to-end encryp-tion solution is available due to the complexity it adds to managing.

• Energy consumption is not measured or evaluated.

3

2 Theory

2.1 Background

During the early years of the Internet the majority of the connected devices were computerswhich purpose was either military or scientific and the number of connected devices werein the hundreds. Since then the Internet has grown in a very rapid pace with approximately500 million devices in 2003 to 12.5 billion devices connected to the Internet in 2010 [15]. Thetelecoms manufacturer Ericsson predicts 50 billion devices to be connected in 2020 [13]. Therapid growth of connected devices has started a new era where people connect almost any-thing and everything to the Internet and has come to be called the Internet of Things.

Over the years, it has become common to connect a device to the Internet through a wire-less local area network (WLAN) which over IEEE 802.11 offers data throughput of up toGbit/s speeds and ranges of up to hundreds of meters. One of the big downsides of theWLAN is that it consumes much energy and many times, the wide transmission/receptionrange is not necessary. Therefore the need of a smaller range and less energy consumingnetwork was needed so the concept of a wireless personal area network (WPAN) was devel-oped. IEEE has developed standards for different WPANs under the standard collection ofIEEE 802.15 where there are ten major areas of development, among others, Bluetooth andLow rate WPAN which now play a big role in the IoT.

However, the focus on cheap and energy saving devices has put the security of those sys-tems aside, sometimes leaving the devices vulnerable for intrusion or takeover. Only recently,the security of the systems has received its needed attention and security mechanisms havestarted being part of specifications as mandatory instead of optional, or even non existent.

2.2 Network Topologies

There are three common network topologies used in the IoT. Star, Tree or Mesh as Figure 2.1shows. In the star topology the edge nodes send data to one central node. In the IoT thiscentral node probably has more computing power and maybe an Internet connection. Thetree topology is a hierarchical architecture where messages are passed up the tree towardsthe root until a node recognizes the message is for one of its descendants, after which itsends it downwards towards the destination. The mesh topology’s strengths are clear in asituation where the network is changing. Nodes may move or paths become unavailable

4

2.2. Network Topologies

Figure 2.1: The three common network topologies visualized in a general case.

Figure 2.2: Example of a ZigBee mesh network

due to interference. In this case allowing the nodes to self-discover the best path to eachother adds robustness to the network. Different implementations of the mesh topology workdifferently, and mesh topologies will be the main focus in regards to routing messages.

An example of a ZigBee mesh network is visualized in Figure 2.2. The mesh networkstructure also opens up for devices to be more energy efficient as the transmission power canbe reduced to only reach the closest neighboring router which routes the message further intothe network.

5

2.3. Security

2.3 Security

Three of the core concepts in information security is confidentiality, integrity and availability,forming the CIA triad. Apart from the CIA triad, other key concepts in information securityare authentication and authorization.

Here confidentiality is tightly coupled with privacy and secrecy and to keep informationsecret to unauthorized entities that should not have access to it. Confidentiality is most ofthe time achieved by cryptography using encryption to make information unreadable for allentities lacking the correct decryption key.

Integrity is based on the concept that information should not be able to be tampered withby an unauthorized party. Integrity can be achieved by cryptography using message authen-tication codes or digital signatures of the information created. If the signature or authentica-tion code of the information is not correct, the integrity of the information can not be verifiedand the information can not be deemed trustworthy.

Availability is based on the concept that information or services should be available whenneeded. Availability can be achieved by ensuring the system serving the information is robustand the infrastructure around it can handle big loads [31].

Encryption

Encryption is categorized into two categories; symmetric encryption and asymmetric encryp-tion. In symmetric encryption, the same key is used for encryption and decryption. Asym-metric encryption, or public key cryptography (PKC), instead has a key pair, one key forencryption and one for decryption. One of the keys is usually held private and one is public.This way the public key can be used for encrypting messages and the private can decryptthe data. Symmetric cryptography has both major pros and cons. The biggest pros are that itgenerally has larger throughput compared to asymmetric cryptography and it needs smallerkeys to achieve the same security. One of the biggest cons for symmetric cryptography isthat there is no efficient, secure way to exchange the encryption keys used for the encryp-tion. Therefore, a lot of focus lies in the safekeeping and distribution of the keys, which hasto be done separately, out of band to ensure secure exchange. Sometimes, out of band de-livery is not viable so the keys has to be transported in band which opens up for attacks.Therefore much weight is put on solutions for secure key transport which many times can beused in combination with PKC. According to NIST, there are only two approved symmetricencryption algorithms which is the Advanced Encryption Standard (AES) and Triple DataEncryption Algorithm, also sometimes called Triple Data Encryption Standard [3, 1].

Symmetric encryption

The most used symmetric encryption today is AES and is recommended by NIST. AES canbe used in different modes of operation depending on what the requirements of the system itis implemented in. Different modes of operation can require one or more encryption keys tobe used depending on if it should be used for encryption only, integrity/authentication onlyor encryption and integrity/authentication together [1]. The modes of operation accepted byNIST is

• ECB: Electronic Code Book. Each clear text block translates to the same cipher textblock regardless of content encrypted before. This mode requires only one encryptionkey and performs only encryption.

• CBC: Cipher Block Chaining. After each clear text block has been encrypted, the cipher-text gets fed and XORed with the next clear text block to be encrypted. The whole cleartext is then fed through this chain until all is encrypted. Thanks to the feedback of thecipher text, each cipher text block will be different even if the clear text, at least if the

6

2.3. Security

earlier clear text was not the same. CBC requires one encryption key and an initializa-tion vector (IV) that is fed as the first value to be XORed with the first clear text. ThisIV needs to be sent to the decrypting part with the ciphertext.

• CFB: Cipher feedback. CFB is a close relative to CBC, but instead XOR the plain textafter the encryption is done and then feds output as next step. CFB also need an IV andone encryption key.

• OFB: Output feedback. OFB takes the output of the encryption and feeds it to the nextblock encryption. At the same time, the same output gets XORed with the clear text togenerate the cipher text. OFB also needs one IV and one encryption key.

• CTR: Counter mode. This mode does not use feedback from any of the earlier blockencryption operations. CTR instead uses a nonce, much like the IV, appended to ainteger counter that is encrypted and then XORed with the clear text to generate thecipher text. Since this mode does not make a stream that relies on earlier blocks beingencrypted, it can be parallelized which makes throughput higher than the other. CTRneeds one nonce and one encryption key.

• CCM: CTR mode with Counter with Cipher-Block-Chaining with Message Authentica-tion Code (CBC-MAC) is a combination of CTR and CBC with message authenticationcode. This mode uses CTR mode for encryption and at the same time generates a mes-sage authentication code with CBC-MAC. This mode needs only one encryption keyand one IV and performs both encryption and authentication/integrity.

To achieve high security, key sizes of at least 128 bits should be used when using AES.Information encrypted with 128 bit encryption keys are considered to be secure beyond theyear of 2030 [3].

Asymmetric encryption

There are several different asymmetric encryption schemes that can either provide encryp-tion and decryption or encryption only, mostly used to exchange common secrets betweentwo or more parties. Asymmetric encryption, or public key cryptography, is often used toencrypt and transport keying material to be used for symmetric encryption over insecuretransport mediums. PKC uses significantly larger keys compared to symmetric encryption toachieve the same security, and PKC is not made to encrypt larger data streams as symmetricencryption is.

The common PKC schemes are

• RSA: RSA is an encryption scheme with support for decryption as well. RSA relies onusing large prime numbers that is multiplied with the clear text. The RSA is built uponthe hardness to factor large prime numbers.

• Elliptic Curve Cryptography (ECC): ECC is based on the algebraic structure of ellipticcurves over finite fields and requires smaller encryption keys, logarithmic comparedto RSA or other discrete logarithm based schemes. This is due to the mathematicalproperties of the elliptic curve. ECC is also more efficient than RSA and other discretelogarithm based schemes with makes it suitable for contained devices with securityrequirements.

• Diffie Hellman (DH): The Diffie Hellman scheme can be implemented in many differentPKC schemes. The main principle in DH is that two parties start with an own secret keyand a number booth know. Booth parties then encrypts number both know with theirsecret key and sends the encrypted version to the other part. Both parts then encryptsthe received message again with their own private key to reach the same common se-cret.

7

2.4. Attacks

To achieve high security, key sizes of at least 3,072 bits should be used for RSA and 256 bitsfor ECC. Information encrypted with those bit sizes are considered to be secure beyond theyear of 2030 [3].

2.4 Attacks

Man in the middle

A MITM attack is an attack where an attacker places itself between two parties as a proxy. Theattack can be either passive or active. When it is passive, the attacker only saves and relaysthe information. When active, the attacker can manipulate the data being sent between theparties.

The attack is visualized in Figure 2.3:

1. Alice tries to send a request to what she thinks is Bob.

2. Eve is in the middle and intercepts the request. She can save the information being sentand/or manipulate the data before sending it further on to Bob.

3. Eve sends the data to Bob.

4. Bob answers the request sent from Alice and sends it to what he thinks is Alice.

5. Eve receives the answer from Bob and either saves the message or manipulates it.

6. Eve sends the request to Alice.

One way to protect against MITM attacks is to use encryption. By encrypting the messagesbeing sent, Eve would not be able to read what the messages say. On the other hand, Evecould still be able to intercept the key exchange messages and manipulate the messages if shewere to find out the encryption key. The way to mitigate this problem is to make sure theauthenticity of whom you are talking to. As such Alice and Bob would have to authenticateone another. If Alice could find a way to communicate with Bob and be sure that only Bobwould be able to read or create messages for communication between them, then Eve wouldhave no way of reading the messages or manipulate them. The mitigation strategy for MITMattacks is to authenticate who you are talking to and make sure that only that party can readthe messages you want them to read and then make sure that the messages are being sentencrypted with a valid integrity check code [31].

Denial of Sleep

It is common for IoT-devices to run on button cell batteries. Some of these devices are placedin hard to reach places, intended only to be maintained once every few years. To achieve suchlong battery time, the device can turn off its transmitter and receiver when not transmitting orreceiving. In other words the devices have a sleep schedule. Successfully disrupting the de-vices sleep by convincing it to transmit and receive for longer periods of time will effectively

Figure 2.3: MITM attack concept.

8

2.4. Attacks

drain its battery, severely damaging its battery life.[29] Denial of Sleep (DOSl) attacks aresimilar to Denial of Service (DOS) attacks. A DOSl attack attempts to keep the device active,abusing commands that can trick the device to read, write or notify. In a home environmenta DOSl attack can for instance drain the battery of motion detectors to enable a home invaderto enter property without being detected. Jonsson conducts experiments on the Power Con-sumption of Wireless sensor networks (WSN), testing cyclic sleep scenarios on BLE, Zigbeeand ANT Sensor nodes [32]. The experiments show a huge difference, one to two orders ofmagnitude, between a high and low duty cycle, where duty cycle is the average awake timedivided by total time per cycle. These reasons suggest using protection techniques againstDOSl attacks is important.

Replay/Playback/Delay attack

In a replay/playback/delay attack, an attacker listens in on the radio medium and records aheard message sent from a device. It can then at a later time replay it as it was heard, and ifthere exist no security mechanisms, the receiving device will think that the sent message wassent by a legit node. A way to amplify the attack would be to jam the radio medium so themessage is not received by the intended receiver and at a later point replay the message, asit would have been sent the first time, this being the delay attack. A scenario for this attackwould be a network with a wireless door lock. A malicious attacker could listen in when aunlock command was sent. At a later point the malicious attacker could replay the heardmessage, and if successful, unlocking the door [44].

Encryption key extraction/sniffing attack

Encryption key extraction/sniffing attacks is when an attacker utilizes a weakness in theencryption key provisioning scheme, or is able to physically extract encryption keys from acaptured device. Many of the key provisioning protocols send out the network encryptionkey in plain text upon network inclusion. A malicious attacker could thus, if present duringthis time, eavesdrop on the inclusion process and receive the network key.

Key extraction can be done if a device does not have its physical interfaces locked down.If so, an attacker could connect to for example physical debug ports on the device to read theRAM or ROM of the device to extract the encryption keys [48].

Routing attacks

Many IoT-devices are mesh enabled with Z-Wave and ZigBee as prime examples. Bluetoothis currently updating Bluetooth 5.0 to add a mesh specification to enable mesh technology[24] [40]. With mesh technology multiple attack vectors are added where one compromisednode can be used to deny the service of multiple nodes [37]. This subsection begins with ashort description of the mesh routing protocols AODV and DSR used in ZigBee and Z-Wave.Oftentimes mesh networks have a network connected gateway which opens up the entirespace of attack-vectors that are prominent on the web. In this section the network connectedgateway is assumed to be uncompromised and as such no attacks on a WSN originating frombase stations are discussed.The routing description is followed by a list of common generalrisks pertaining to mesh topology routing attacks, along with mitigation techniques.

Ad-Hoc On Demand Distance Vector Routing

Ad-Hoc On Demand Distance Vector Routing, AODV, is a reactive, on demand routing pro-tocol. This means a route is only created when a device wants to initiate contact with anotherentity in the network. The initiating device checks its routing table, later described, and ifit cannot find an entry for reaching the desired entity it broadcasts a route request (RREQ)message to its neighbors. The receiving devices forward the RREQ to their neighbors until

9

2.4. Attacks

it reaches either the destination node or a node with a fresh enough route to the destina-tion node. This node replies with a route reply (RREP) to the previous node, which updatesits routing table. The RREP message is propagated back until it reaches the original RREQsender. The sender now knows which neighbor has a path to the desired node and can trans-mit data. If a route could not be found, or if a route is considered to old to use further, a routeerror (RERR) message is sent notifying the source node that a new route discovery processneeds to be issued [6].

Entries in the routing table contain the following fields:

• The destination node.

• The next hop towards that node.

• The cost to get there, could be hop count or other metric to describe how good a routeis.

Dynamic Source Routing

Dynamic source routing (DSR) is a proactive routing protocol that relies on routes being setupbefore the need to use them. This results in every node, or a network controller, needs to havea complete routing table with routes to every node, and it must know the neighbors of everynode to be able to construct routes. In contrary to AODV, DSR sends the complete route withits packages leaving more routing overhead. On the other hand, since every route should besetup beforehand, messages can be sent fast and reliable since the route is known before [46].

Selective Forwarding

A selective forwarding attack can be used to launch a DOS-attack where the malicious nodecan choose which of the packets that pass through it to forward and which packets to drop.With improper authentication of messages they can be modified before forwarding [34]. Wall-gren et al.[37] implemented the selective forwarding Attack against RPL with a maliciousnode forwarding all routing messages that passed through it and dropped all else. This sim-ple technique stopped the routing protocol’s self healing mechanism as the messages that testthat the routing graph is still correct, the routing graph Information Object, are forwardedwith no problems. To mitigate the risks and damages of a Selective forwarding attack multi-ple different disjoint paths can be used. However it is often hard and not always possible tocreate entirely disjoint paths. Using dynamic paths can also help, oftentimes there are pathsthat are nearly as efficient as the original path in the destination oriented directed asyclicgraph (DODAG). Many attacks are easily subverted by encryption which makes the rout-ing messages indistinguishable from data messages and as such the attacker must drop all,none or guess. On application level, if expected sensor data does not arrive it can report lostmessages to the underlying routing protocol asking it to construct a new path.

Sinkhole

When executing a sinkhole attack an attacker tricks legit nodes in a network to route its pack-ages through a node under its command. The attacker announces that it has the best pathto the destination node or gateway available. When the packets arrive for forwarding theattacker has full control of what to do with it. A sinkhole attack on its own is in most casesnot too detrimental to the WSN service, but combined with other attacks it can bring downan entire network. Nodes that rely exclusively on internal mechanisms to determine theirpaths are immune to sinkhole attacks as the malicious node cannot change any other nodespath. Using multiple DODAG instances allows for an IDS, located in the base station/sink orsome other less constrained device, to inspect the paths and detect potential sinkholes [37].A malicious node that has advertised a very low rank, in RPL a node with a lower rank than

10

2.4. Attacks

Figure 2.4: The red node broadcasts overstates its routing to all available nodes with largetransmitter power as indicated by the blue circle. The ones in range to reply are indicated bythe purple circle.

another is supposed to be closer to the root, might be later rejected by the routing protocolas the nodes realize their messages are not reaching their destination when using the sink-hole node. If the node has been compromised in such a way that its keys are revealed to theattacker, the attacker may instead use a high transmission powered device such as a laptopto spoof a node. The laptop outclasses all other sensors in performance, radio transmissionand receiving. The laptop might as such have a great path to the root through directly trans-mitting, or forwarding it to a transmitter closer to the base station through a wormhole [34].Figure 2.4 shows the basic concept of a sinkhole attack. It also shows that bi directionalitychecks or self healing mechanisms are required to maintain the network. Without any suchmechanism, the network might break without malicious activity simply due to a differencein transmitter strength between two nodes.

Wormholes

In a wormhole attack the attacker tunnels messages from one part of the network to another.Commonly two malicious nodes collude and use a high bandwidth out of band low latencytechnique to communicate with each other. If the first malicious node is positioned in a clus-ter of benign nodes and the second is close to the root or base station, the first malign nodemay provide such a good path to the root that all nearby nodes use it. This way the wormholewill become a sinkhole and can be combined with some other type of attack, be it selectiveforwarding or eavesdropping. The wormhole attack can be combined with a sybil attack toreduce chances of detection [34]. wormholes can be used to abuse Routing Race Conditions.Routing Race Conditions typically occur when a node will take some action based on the firstinstance of a message it will receive, and ignore other messages of that type. The attacker canutilize the wormhole to make sure a node of their choosing gets the first message through[5]. If the attacker can identify that the messages being sent are of a type where routing raceconditions exist, encryption and authentication does not thwart the attack as the messagesare unmodified. If the wormhole has the fastest way to forward a message from one node toanother, the wormhole can keep forwarding a chosen nodes messages first in hopes that even-tually it will have successfully created a Routing Race Conditions. Routing Race Conditionattacks attempt to confuse the nodes in the network as to how the topology looks. Anotherway of confusing the network is by constantly forwarding messages between nodes throughthe wormhole, making them think they are neighbors.

11

2.4. Attacks

Figure 2.5: The wormhole attacks allows the orange nodes to provide the best possible/equalpath for all nodes in the left neighborhood in regards to hops required to reach the root R.

Mahajan et al. [43] discusses techniques to detect in band wormholes in the networkby considering delay. Using a delay statistic an IDS can find incompatible hop delays andend-to-end delays. The biggest time sink during transmission takes place in between hops,where a device receives and retransmits a message. As such an anomaly can be detectedwhen a node is supposed to use only a few jumps but the time it takes indicates there arehops being made that were not advertised. A node that transmits over nodes that are partof the wormhole may also experience unexplained traffic congesting and slowing down itstransmissions. As such the end to end delay will increase for nodes that are not part of thewormhole. The effectiveness of this method depends on the amount of compromised nodes,their location in the network, and how much the wormhole lies about its routing capability.

Hu et al. [65] present two types of Packet Leashes as a detection mechanism for worm-holes, Geographical Leashes and Temporal Leashes. For a Geographical leash, in general,a node must know its geographical position and have loosely synchronized clocks. Eachmessage is extended with the current time and the position of the transmitting node. Thereceiving node calculates the distance between the two using its own estimation of time andposition and compares it to an upper bound for normal communication. If messages travelover the threshold a wormhole can be suspected. wormholes that relay data between twonodes that are geographically close but with an interfering obstacle between them will not bedetected. The temporal leash requires tightly synchronized clocks, which puts extra require-ments on hardware. When a node transmits a message through the network it appends thecurrent time. The receiving node compares its current time to time attached to the message. Ifthe time difference is above a threshold the message is disregarded. The message could alsobe built with an expiration time instead. Both of these solutions assume that messages areproperly authenticated or else the wormhole can go undetected in combination with a spoof-ing attack. When each node signs its position it also cannot get away with claiming to be attwo places at once, as a receiving node may calculate the validity of how much another nodeclaims to have moved. A benign node may rebroadcast the fraudulent messages to convinceneighbors that a node belongs to an attacker.

Sybil Attack

A sybil attack is when a single node in the network forges multiple identities. Rememberingthe technique from selective forwarding of trying to build multiple paths to the root, theeffects of a sybil attack are considered. If node A is part of the first, but not the second, pathand B is part of the second path, the paths are not disjunct if A or B are fake nodes created bythe one node that is forging identities, thus tricking the routing protocol as seen in Figure 2.6.In [5] by Karlof et al., the sybil attack is related to clone ID attacks, which is when an attackercopies the identity of one node to others. In the clone ID attacks you use multiple physicaldevices pretending to be one, in sybil one physical device makes up multiple logical devices

12

2.4. Attacks

[37].Let us assume that each device in a network has a unique address, a sybil node may picka random address, creating a false identity, or it can steal an address from another node.Stealing an address is easier to do if the actual device with that address is in some wayout of order during the process, for instance by interference or physical destruction [27].An attacker might cycle through identities, creating a huge amount of devices over a longtime by pretending to leave the network and that new nodes arrive. This might circumventsimple methods that blacklist devices that act suspicious by refreshing the active sybil nodesidentities.

Yang et al. in [30] propose a general RSS based sybil detection mechanism. They use astatistical approach in which each point available to record the signal strength received fromdifferent nodes does so. When each recording device combines their data an N-dimensionalpoint is created. Multiple points from the same node should be in the same area, while othernodes should be in a different physical position. The detection mechanism was in their setupsuccessful but it does not study how the false positive or false negative-rates depend onthe amount of recording points, clustering nodes in fewer dimensions which might be ofinterest for feasibility in practice. This approach assumes nodes are still in regards to theirenvironment. Using an RSS-based approach to detecting sybil attacks limits the users abilityto place devices close to each other. Devices must have a minimum distance from each otherto not trigger the a sybil attack detection response. The authors do test this and conclude thatwhen devices have a greater minimum distance between them the chance for false positivesdiminish.

More common is the cryptographic approach such as the ones in [39, 27]. The crypto-graphic approach to sybil attacks tries to force fake nodes to fail thanks to some kind ofnetwork wide challenge. For instance all nodes may a be provided a nonce which they areto use as an argument to a function. Each node must within a set time frame answer withthe correct response. Any node that does not succeed becomes less trusted, and any nodesthat reach a threshold are kicked out of the network. This is intended to work by using thefact that one node will not have time to compute the correct answer for all its nodes and assuch the network will build an understanding of sybil nodes in the network. Of course thishas a drawback in that nodes must calculate and transmit messages with no relation to theirspecific purpose, decreasing the devices battery life. A device creating sybil identities mightnot be on an equal playing field as the devices it is impersonating in regards to computationpower. For instance a captured node might be replaced by a computer with high enoughcapability to calculate and respond to multiple challenges, especially if the device is capableof using more than one radio transmitter.

Newsome et al. [27] present a taxonomy of how a sybil attack may take form, as depictedin Table 2.1. Direct Communication is when malicious nodes use their sybil identities forcommunicating with legit nodes. Indirect communication instead means that the maliciousnode presents the sybil node as one of its neighbors rather than announcing itself under anew identity. They also present some concrete examples of defenses, such as Radio Resourcetesting, where a node decides to verify some other node. Using this technique the suspectingnode challenges each of its neighbors to each transmit on a different channel. If the attackerhas created multiple nodes and cannot transmit on all channels it is supposed to, the lack ofa message by the suspected node is considered a sybil node detection. When a group of cap-tured nodes in a neighborhood is as large as or larger than the amount of channels availablethe captured nodes can cover all channels thus covering up for their sybil descendants. Usingindirect communication can prevent legit nodes from directly challenging a sybil node, as allsybil nodes are neighbors of only malicious nodes.

13

2.4. Attacks

Table 2.1: Depiction of which sort of communication, identity and simultaneity. *If there is atime period during which nodes vote a non-simultaneous attack might be applicable. **Whennodes can join more frequently than a node is allowed to transmit. For instance new nodesmight be allowed to join every minute but the network is flooded with data only once anhour.

Communication Identities SimultaneityDirect Indirect Fabricated Stolen Simultaneous Non-Simultaneous

Distributed Storage x x x x xRouting x x x xData Aggregation x x x x xVoting x x x x x x*Resource Allocation x x x x x x**Misbehavior Detection x x x x x x

Figure 2.6: The node S believes itself to have three disjunct paths to the destination D whichis true unless node 1, 2 and 3 is in reality only one node conducting a sybil attack.

Hello Flood

The hello flood exploits the fact that it is common for nodes to broadcast hello packets tomake themselves known to neighboring nodes or to keep connections active. The receivingnodes usually assume they are in normal radio transmission range, which might not be truefor a HELLO flood attack. An adversary announcing its arrival to the network with a greatpath to the base station might, if the transmission strength is enough, make all nodes inthe network consider it as its parent. An out of reach node might realize it cannot routeits messages through this neighbor any longer and try to use its local neighbors to find anew path, but if all neighbors are in the same state the network might get stuck in a state ofconfusion [34].

In RPL the HELLO flood is automatically mitigated without an IDS. The HELLO broad-cast with the best possible path does trick the nodes into believing it is a great path but RPLuses link-layer acknowledgements to verify a path. If no link-layer acknowledgements arereceived another route is chosen. The new path is not dismissed by the nodes which are inrange of the attacker, which makes the end result a sinkhole (given that the hello message wasof the type that exaggerates its capabilities to reach the base station) [37]. This is close to thesuggested solution in [34] which suggests verifying the path by checking its bi-directionality.In AODV the HELLO flood can be implemented as a series of RREQ-messages. If a RREQ-message is created and transmitted asking for a route to a non-existent node in the networkthe message will propagate through potentially all the nodes. Consecutive transmissions ofRREQ-messages may create enough useless chatter in the network to disrupt the expectedservices [36] suggests a clustering based reputation technique where a cluster head is chosenand used to keep track of cluster nodes’ reputation. A node that transmit too many RREQmessages gradually loses its reputation and will be disregarded. There are many different

14

2.5. Bluetooth

techniques to handle HELLO floods in AODV and most suffer from false alarms, high rout-ing overhead or increased delays and messages dropped.

2.5 Bluetooth

Classic Bluetooth was developed to connect the worlds of computing and communication byconnecting cell phones and laptops/personal computers. Its main application did howeverappear to act as a link to send and receive audio between a cellphone and a headset. As thetechnology got more widespread the use areas became wider and the data rate requirementsstarted to grow when streaming of stereo music and file downloads became core applications.The data rates of Bluetooth started with about 1 Mbps for v1.1, 3 Mbps for v2.0, and 54 Mbpsfor v3.0 [25].

In December 2016 the Bluetooth 5.0 Specification was adopted by the Bluetooth SpecialInterest Group, (SIG), to supersede Bluetooth 4.2 which was released in December 2014. Thefirst Bluetooth standard which incorporated functionality for Low Energy was Bluetooth 4.0,released in June 2010. Each version of the protocol specifies both Base Rate/Enhanced DataRate (BR/EDR) and Low Energy [59]. Bluetooth 5.0 is marketed as a new version with up tofour times the range, two times the speed and eight times the broadcasting message capacity.

Security in Bluetooth Low Energy

Bluetooth Low Energy, or Bluetooth Smart, was introduced as Wibree by Nokia in 2006 andbrought to the Bluetooth SIG. It is designed to enable devices to be fully operational for yearsusing a button cell battery. BLE is most commonly used in fitness products, security andproximity sensing, health and wellness as well as general smart home applications. BLE usesthe free-to-use ISM 2.4 GHz Frequency band.Each Bluetooth Classic channel has a bandwidth of 1 MHz, and each packet is sent on oneof the 79 designated Bluetooth channels. BLE channels are instead 2 MHz wide and uses 40different channels. Three of them, spread out over the available spectrum to minimize riskof crippling interference on all of them at once , are for advertisement and the other 37 areused to transmit data packages. [25] Due to the 2.4 GHz band being very crowded, Bluetooth5.0 redefined the advertisement channels as to no longer be the only advertisement channels.To ensure backwards compatibility the 3 common advertisement channels are now PrimaryAdvertising channels, and the other channels are Secondary Advertising as well as data. Thisallows for beacons, simply put Bluetooth transmitters, that broadcast data rather than connectand pair with other devices to pick a channel which is not as congested as the advertisementchannels are likely to become.

As noted BLE uses frequency hopping over its 37 data channels and a packet is always senton each hop even if it contains no usable data. Frequency hopping means quickly switchingcarrier in a predetermined pattern (Not to be confused with adaptive Frequency Hopping).In BLE the pattern is a fixed hop increment after a fixed time, which makes BLE slightly lesshard to sniff than more advanced, difficult to predict, patterns. This does not imply a randomhop increment or interval gives security, as a sophisticated attacker might sniff all channelssimultaneously.A Link Layer package looks as described in Figure 2.7 and is used in both advertisementchannel packets as well as in data packets. There are two differences between the packagedescribed in the Figure, Bluetooth 4.0-1, Bluetooth 4.2, and Bluetooth 5. The payload is re-stricted to 296 bits, 37 bytes, in version 4.0. In 4.2 it is allowed a maximum size of 255 bytes(39 for 4.0-1 and 257 for 4.2 and 5 if the Header- and Length-field is counted). Bluetooth 5uses a 2 byte preamble when using LE 2M PHY. Below as well as in Figure 2.2 the differencesbetween LE 1M, LE 2M and LE Coded PHY are described. LE 1M and LE 2M are the two LEUncoded PHYs, where 1M means a symbol rate of 1 Msym/s, where each symbol is one bit.2M is the same except with the symbol rate 2Msym/s.

15

2.5. Bluetooth

PHY Modulation Scheme Access Header Payload Data RateLE 1M 1Msym/s Uncoded Uncoded 1 Mb/sLE 2M 2Msym/s Uncoded Uncoded 2Mb/sLE Coded 1 Msym/s S=8 S=8/S=2 125 kb/s or 550 kb/s

Table 2.2: Bluetooth PHYs, modulation, coding and data rate.

Figure 2.7: The frame format of a Link Layer package in BLE 4.0

BLE also supports an optional error correction coding known as LE Coded PHY. LE CodedPHY can be error corrected with S = 2, where 2 symbols are used per bit, or S = 8. LE CodedPHY uses the 1Msym/s model, and therefore achieves 500 kb/s for S = 2 and 125 kb/s forS = 8 [59].

Pairing Method

Before Bluetooth 4.2 there were three ways for Low Energy devices to establish a connectionbetween each other. These three key exchange and pairing algorithms are used when at leastone of the two devices predates Bluetooth 4.2. Devices of version 4.2 or 5.0 can be forced touse Secure Connections Only mode, which requires the use of a non legacy-pairing methodand as such it makes the device incompatible with devices that run earlier versions of theprotocol. As seen in Figure 2.8, the pairing begins with the devices exchanging their publicfeatures to decide which pairing method to use. The three available legacy pairing algorithmsare

• Just WorksFor devices which lack a keyboard, for instance a headset pairing with your cell phone.This legacy pairing always uses the same six digit Temporary Key (TK), 000000.

• Passkey EntryDisplays a six digit PIN on one device and manually input into the other device, toavoid communicating the TK over the air.

• Out Of BandExchanges the pairing information using some other technology than Bluetooth. OutOf Band can only be used if the devices have interfaces compatible with each other, forinstance near field communication. This pairing method uses a 128 bit value for its TK.

Bluetooth 4.0 connections pairing contained very little protection against eavesdroppingand MITM attacks [18] which may have inspired the addition of LE Secure Connections inversion 4.2.LE Secure Connections uses, just as BR/EDR, the well established anonymouskey agreement protocol Elliptic Curve Diffie-Hellman (ECDH) [4].

16

2.5. Bluetooth

Figure 2.8: BLE legacy pairing methods

In the first phase of pairing, device information is exchanged containing max key sizes,version and I/O-capabilities. After the devices have traded data they select a pairing methodthey have in common which means that if a version 4.2+ device pairs with a 4.0-device it willuse a Legacy Pairing method.

Attacks on Bluetooth Low Energy

Man In The Middle

2319 BT5 [18] LE Legacy Pairing has no protection against eavesdropping, as the TK is pre-dictable or easily calculated, given the eavesdropper is present during the pairing. Accordingto the Bluetooth 5.0 documentation regarding the Passkey Entry "The passkey Entry methodprovides protection against active MITM attacks as an active MITM will succeed with a prob-ability of 0.000001 on each invocation of the method." [4] which is challenged by [53], whostates that an attacker can brute force the correct passkey TK and trick the master as no matterthe previously committed confirm-value from the attacking slave, it can find a value for its"random" number that satisfies the confirm value even if the TK is one-time-unique. Figure2.9 shows how two devices may pair using LE Secure Connections Just Works and NumericalComparison, as described by the Bluetooth 5.0 specification. Na, and Nb are nonces and Cbis a confirm value to be committed. Apart from the fact that Secure Connections uses Pub-lic Key cryptography the broken function to calculate the confirm values has been changed,which reduces the risk of the attack proposed by [53] to be successful.

A simple passive eavesdropper is described by Giwon and another by Ryan[18, 54]. Prac-tical feasibility has been shown by open source BLE MITM frameworks such as Crackle andBtleJuice that exploit the vulnerabilities described below.

To follow and understand a hopping connection, the eavesdropper needs to know the hopinterval, hop increment, access address and Cyclic Redundancy Check (CRC) init. The accessaddress can be determined by monitoring a data channel looking for empty packets. Emptypackets are identifiable by their headers. This means the bitstream can be read, and the 32 bitsbefore the empty packet header provides a possible access address. There are two bits in theempty-message header that change, and as such only 14 bits of the header can filtered overwhich generates a lot of false positives. A candidate access address that is observed multipletimes can be with some confidence treated as the target Access Address.

The CRC is important to get right as any message with an incorrect CRC will be rejectedby the receiver. A CRC is a cheap way to protect from bit errors that occur without intent suchas interference or a bad cable however the CRC does not provide cryptographic integrity andcan be forged quite easily. CRC should never be used as an integrity check, only as a mean todetect transmission errors [42, 59]. To get the correct CRC one must Figure out the value ofCRC-init which varies between connections which is done by taking an incoming candidatepackage and seeding the Linear-feedback shift register with the CRC. The bits of the CRCis then fed through the LSFR in reverse order which leaves a possible CRC-init in the CRC-

17

2.5. Bluetooth

Figure 2.9: BLE Secure Connections Just Works and Numerical Comparison.

register. When one possible CRC-init has been seen multiple times it can be assumed to bethe CRC-init [54].

The Hop interval is easy to calculate, here in milliseconds.

∆t1.25 ˚ hopInterval

The hop increment is recovered by receiving a message on one data channel, hop to the nextand measure the time it takes before the second package arrives, and from there calculate thehop increment [54].

Having all these pieces means all the data required to inject messages into the stream.This relies on the malicious attacker being able to inject the message during a very thin timewindow, during which the receiver expects a message and making the original message dis-appear, either by having a strong transmitter with a signal strength that overrides the originalmessage or by introducing interference in the legit connection.

18

2.5. Bluetooth

Figure 2.10: General authenticated message.

Replay/playback attack

When fast connection setup and fast data transfer is required, authenticated unencrypteddata can be sent between two devices. To protect against replay attacks a SignCounter is used.Each device shall have a connection signature resolving key (CSRK) for each connection toa peer. Signing is then performed according to NIST Special Publication 800-38B. The MACgeneration function is defined as: MAC = CMAC(K, M, Tlen) Where K shall be the CSRK, Mshall be the message concatenated with the SignCounter. Tlen is the bit length of the MACand shall be 64 bits. The MAC and SignCounter is applied to the message as Figure 2.10describes. This mode is known as LE Security Mode 2. A receiving device protects itselfagainst replay attacks by comparing previously received SignCounters with the current oneand ignoring data with an outdated SignCounter.

When using LE Secure Connections to pair devices both the Initiating and Non-Initiatingdevice generate a random nonce which is used to protect against replay attacks. New Noncesmust be generated with each initialization of the pairing protocol to improve security [59].

Denial of Sleep

Uher et al. [29] applies five different DOSl-tests to a Fitbit running Bluetooth 4.0 and mea-sures the time until battery depletion. Utilizing that BLE allows for simultaneous write/readoperations, the authors were able to reduce battery time from 120 hours to just 6 hours, ora 95% decrease. Potential mitigation techniques against DOSl attacks are described in thefollowing subsections.

Resolvable Private Addressing

Bluetooth 4.2 defines Resolvable Private Addressing (RPA) where the devices produce a hashon the form hash = ha(IRK||prand) Where IRK is the Identity Resolvement Key and prandis a random number. The address message is sent as hash||prand The receiving device shouldhave a list of all paired devices with white listed IRKs provided after the pairing process iscomplete. The device tries to resolve the address by checking over its IRKs for a key thatsatisfies hash-received = ha(IRK||prand) where prand is extracted from the message. Assuch, as long as the attacker cannot find the IRK it cannot spoof a white listed device to forcethem to carry out operations [4].

Link Layer Device Filtering The Link Layer has Device filtering. Devices may have poli-cies for the Advertising state, Scanning State and Initiating state. These policies exist to min-imize the number of devices of which to respond to which is very relevant to avoid sleepdenial. The filtering can be used to avoid processing scan requests, which are requests fromentities in the proximity for a device to identify itself, and connection request, where a deviceattempts to establish a connection.

• White List The before-mentioned white list can be used on the Link Layer by the Hostcreating a copy of the white listed devices, the RPA is then to be resolved and checked

19

2.6. ZigBee

against the list before waking up the Host thus preserving resources when a non-whitelisted device attempts to wake it [4].

• Advertisement filter Policy Only process Scan and Connection requests from whitelisted devices.

• Scanner Filter Policy If Extended Scanner Filter policies are supported, only allow ad-vertising packets from devices on the White List.

• Initiator Filter Policy Only White Listed devices should be processed.

• Black ListUher et al. [29] propose a Black List as well as a White List. Every time an RPA isresolved it is added to the Black List. As long as a devices IRK is still unknown, thiswould mitigate the risks of a potential Spoofing Attack where the attacker takes thename of one of its RPA’s. One drawback of this is that a new RPA must be generatedwith every connection instead of periodically refreshed.

Vulnerabilities in Bluetooth- conclusion

Table 2.3: table with different Bluetooth versions and if the version is considered secure dueto implemented security measures.

Attack\Protocol Version Bluetooth Bluetooth Bluetooth4.0 4.2 5.0

MITM Yes No* No*Key extraction/ Yes* No* No*EavesdroppingReplay/Playback No* No* No*Denial of Service Yes Yes Yes

Denial of Sleep Yes* Yes* Yes*Routing

- Selective Forwarding Yes* Yes* Yes*- Sinkhole NA NA NA- Wormhole NA NA NA- Hello flood NA NA NA

No Native build in SecurityNo* Opt in security availableYes Directly vulnerableYes* Vulnerable under specific circumstances

2.6 ZigBee

The ZigBee technology has become widely popular due to its characteristics of low powerand low cost and has got a foothold in, among others, home automation and light controlapplications. The ZigBee specification is open for anyone to use but for a product to be Zig-Bee certified, it has to go through a certification process by the ZigBee alliance for the sake ofinteroperability between different manufacturers. The ZigBee specification defines a networklayer and an Application Support Layer (APS) in the application layer for ease of implementa-tion for manufacturers. For the two lower layers, PHY and MAC, in the ZigBee stack, ZigBeeis is built on the IEEE 802.15.4 standard and thus get features of different network topolo-gies, radios over either 2,4 GHz Industrial, Scientific and Medical,ISM ,-band or sub-GHz(868/915 MHz for Europe/North America) and defines frame formats suitable for low data

20

2.6. ZigBee

Feature Zigbee 2006 ZigBee 2007 Zigbee ProSize in ROM/RAM Smallest Small BiggerStack Profile 0x01 0x01 0x02Maximum hops 10 10 30Maximum nodes in network 31 101 31 101 65 540Mesh networking Yes Yes YesBroadcasting Yes Yes YesTree Routing Yes Yes NoBandwidth used by protocol Least More MostFragmentation No Yes YesMulticasting No No YesSource Routing No No NoSymmetric Links No No YesAES 128 bit Yes Yes YesHigh Security No No Yes

Table 2.4: ZigBee difference overview

Figure 2.11: The ZigBee stack network model

rate and low energy consumption communication. Thanks to the openness of 802.15.4, thereexists a plenitude of micro controllers and transceivers that implement the 802.15.4 standardthat manufacturers can choose upon depending on demands of energy consumption andperformance. The ZigBee network stack reference model is shown in Figure 2.11.Gislason[19] provides a comparison between different versions of Zigbee which can serve as a quickoverview, as seen in Table 2.4.

There are three types of devices in a ZigBee network; the ZigBee coordinator, ZigBeerouter and ZigBee end device. The ZigBee coordinator is an IEEE 802.15.4 coordinator andcoordinates the ZigBee network. It also houses the Trust Center (TC) which should be thedevice that the whole network should base its trust on. The TC should distribute and manage

21

2.6. ZigBee

Figure 2.12: The setup of a ZigBee frame. MAC is in this Figure refereed to as MessageAuthentication Code

all encryption keys used in the network. If the ZigBee network were to be controlled by adevice connected to the Internet, the coordinator can also act as a gateway to the Internetconverting IP-packets to commands in the ZigBee network.

A ZigBee router is a device that relays or routes messages between devices in the network.The ZigBee router can thus be used to extend the network range such that a device does notneed to be in direct range of another device to communicate with it. A ZigBee router can bothact as a router and at the same time have an application specific purpose just as an ZigBeeend-device.

The ZigBee end-device is a device in a ZigBee network that has an application specificpurpose and does not act as neither a coordinator or a router. Since it has limited functionalityand not has any further responsibilities other than its specific purpose, it can be implementedwith very limited hardware demanding low energy consumption. Hence a ZigBee end-devicecan operate with only a small battery lasting months or even years.

Security model in ZigBee

To achieve confidentiality and integrity/authentication in ZigBee AES encryption used inCCM* (a variant of Counter mode with CBC-MAC) mode with 128 bit keys. The ordinaryCCM mode is a block cipher operation mode which provides both encryption and integritybut CCM* also adds functionality for encryption-only and integrity-only depending on thepolicy of the network. For replay protection, a frame counter is present for the network layerand one frame counter is associated for each pair of devices that have been communicatingwith each other. The frame counter is 32 bits long and is not to be reset unless the TC issuesa new Network key. The device should drop all frames which does not have a frame counterlarger than the last one received to ensure message freshness and that the frame has not beenreplayed by an attacker.

There are two kinds of AES keys in the ZigBee 3.0 [66] specification which are a NetworkKey and Link Keys. The Network Key is used for broadcast messages to many devices.This key is the same for all nodes in the network and is used to secure network frames atthe Network layer. The other kind of key is called a Link Key and is used between twodevices for end-to-end encryption which is applied in the APS layer of the network stack.The network key is delivered by a TC using either a pre-installed Link Key to the TC, or witha default key specified in the specification. If the key used is the default one, an attacker

22

2.6. ZigBee

could eavesdrop on the exchange of the network key and decrypt the message easily sincethe default key can be considered public knowledge. Link Keys are supplied by the trustcenter and transported to the devices from the TC with TC Link Keys. For applicationsthat can accept a moment of vulnerability, a well known Link Key can be used, such as thedefault TC Link Key that is specified in the specification, to transport the new Link Keyseither for communication between two devices or for a new TC Link Key. One other securityconsideration is that even though the Link Key exchange is encrypted with a Network key,a malicious device that might have got hold of the Network Key can eavesdrop the LinkKeys transported in the network since they are transported encrypted with only the NetworkKey that all nodes in the network possesses. The initial key exchange is however in practiceusually performed by transmitting the message with very low transmitting power resultingin the need of pairing devices to be in very close proximity to the TC, usually 0.5 to 1 meter.Even though this makes an attack harder to perform, it does not fully mitigate the risk that anattacker gets hold of sensitive keys since the attacker can have large gain antennas to receivethe key transport messages anyway.

The ZigBee specification states that "The level of security provided by the ZigBee security ar-chitecture depends on the safekeeping of the symmetric keys, on the protection mechanisms employed,and on the proper implementation of the cryptographic mechanisms and associated security policiesinvolved. Trust in the security architecture ultimately reduces to trust in the secure initializationand installation of keying material and to trust in the secure processing and storage of keying ma-terial." [66] but thanks to the constraints of low cost devices, out-of-band mechanisms forkey-delivery or pre-installed, unique, keys is not always applicable in practice which has theresult of initial sensitive keying material being sent unprotected which can compromise thewhole network.

Possible Attacks on ZigBee

Since the level of security of the network depends on the transportation and safekeepingof the symmetric encryption keys, many attacks can be performed if those keys are com-promised. Most of the security mechanisms can be bypassed if the keys are compromisedand an attacker can act as a legit device. Zillner [68] has showed that it is trivial to gethold of network keys when devices join a network and can after the key compromise sendcommands that seems to come from a device in the network since the command is encryptedand integrity protected using the network key. The ZigBee Alliance was informed about thissecurity flaw but since the network is only vulnerable for this attack during a very limitedtime frame and that the attacker must be in very close proximity to the TC, a statement wasissued stating it not a big issue [67], although it was also mentioned there are ways to increasethe chance that this particular situation happens which could be is to jam the communicationbetween one device and the controller of the network. The user will then try to re-pair thedevice to the network and the attacker would then be able to listen in on the network keybeing transmitted.

Encryption key extraction/eavesdropping

Other ways to get hold of encryption keys is to physically get access to a device. Since one ofZigBees big focuses is cheap devices that can be put almost everywhere, it can be very easy toget physical access to a device and since the device is built to be cheap, it will most probablynot be built tamper resistant. This opens up to read the memory of the chip and thus gethold of stored encryption keys. Goodspeed [20] created a tool that can read the memory oftwo specific popular System on Chips and thus can get hold of encryption keys stored on the

23

2.6. ZigBee

device.

More advanced attacks have been showed in [11] where differential power analysis wasperformed to extract keys from commonly used Light Bulbs from Philips. They did even takethe attack to a next level by creating a worm that spread to nearby lamps by extracting thesigning key for over-the-air-updates and then sign their own version of a custom firmware.As a proof of concept, they mounted a drone with a transmitter and from a long distance man-aged to take over several bulbs in a building and updating them with the custom firmwareto blink in a specific pattern.

Man in the middle

Since ZigBee is vulnerable to encryption key extraction/eavesdropping, it is also indirectvulnerable to MITM attacks since if a malicious node gets hold of the network key, it canalter or chose to drop messages if a message between two nodes needs to be sent through themalicious node.

Replay/Playback attacks

If the ZigBee network is configured to use the supported frame counter for its communica-tion, a pure replay attack where an external attacker just retransmits an encrypted messageis not viable. This is because the frame counter makes sure that frames received is fresh andthat only devices with knowledge of the encryption key should be able to craft new, legit,messages. If a network key were to be compromised, other, more extensive attacks would bepossible to perform like injection of messages that would appear to be sent from legit devices.

Denial of service/sleep

Most of the DOS attacks on ZigBee is focused on the 802.15.4 layers, PHY and MAC, of theZigBee network stack.

Cao et al. [14] has shown with its attack Ghost-in-ZigBee, both in simulation and in prac-tice, that it is possible to perform energy depletion, DOSl, on a ZigBee network. Ghost-in-ZigBee performs its DOS attack by sending a high number of bogus messages to deplete theenergy recourse of the device under attack. This can be done even if encryption keys arenot known since the bogus message still has to be processed to validate if the message isa correct message or not. Further, since IEEE 802.15.4 uses the CSMA/CA access, which isa collision avoidance method when using wireless communication, an attacker can occupythe communication channel so that other devices may not have the ability to send its validmessages, thus resulting in a denial of service. In the practical experiment when using theGhost-in-ZigBee attack, the lifetime of a device was reduced to only 6-8% of its original batterylife.

Routing attacks

Since the routing protocol is based on AODV, the attacks that can be performed on AODVcan most of the times also be used on the ZigBee routing protocol. Since all routing attacksare insider attacks, it is assumed that the attacker has got a device included in the networkand can act as an included node.

Selective Forwarding

AODV has no support for avoiding selective forwarding attacks since a malicious node cansimply just chose to drop packages. A combination of selective forwarding and sinkholeattacks have been executed on AODV in, among others [23, 47, 58]. All attacks performed

24

2.7. Z-Wave

resulted in decreased payload delivery ratios and throughput with increased end-to-end de-lays.

Sinkhole

AODV is also vulnerable for sinkhole attacks. Attacks have been demonstrated in amongothers, [47, 23, 56]. The way to perform a sinkhole attack in AODV is to change the hop countin route request messages when a route discovery process is initiated. In AODV, there is nomechanism to notice such behavior which makes AODV vulnerable to the sinkhole attack.

Wormhole

Wormhole attacks on AODV has been presented in among others, [33, 35, 57] and can becomea problem if an attacker gets a node included in the network.

Hello Flood

In AODV, the hello flood attack translates to a route-request-flood (RREQ-flood), where anattacker continuously initiates a route discovery process. This generates a lot of traffic in thenetwork, and an attacker could also send RREQ for an address that is not in the network withthe result of every node trying to find if it has that node as neighbor. RREQ-flood attackshave been demonstrated with success in [38, 52, 12].

Table 2.5: Table with different ZigBee versions and if the version is considered vulnerable dueto lack of implemented security measures.

Attack\Protocol version ZigBee 2004 ZigBee 2007 ZigBee 2015(0x01) (0x02) (0x03)

MITM Yes Yes YesKey extraction/ Yes Yes YesEavesdroppingReplay/Playback/Delay No* No* No*Denial of Service Yes Yes YesDenial of Sleep Yes Yes YesRouting

- Selective Forwarding Yes Yes Yes- Sinkhole Yes Yes Yes- Wormhole Yes Yes Yes- Hello flood Yes Yes Yes

Yes Directly vulnerableYes* Vulnerable under specific circumstancesNo Native build in SecurityNo* Opt in security availableNA Not applicable to this protocol

2.7 Z-Wave

Z-Wave is a WPAN protocol stack that has become a very popular home automation pro-tocol stack and was founded by a danish company Zen-sys which was bought by the chipmanufacturer Sigma-designs in 2008. In 2005, the Z-Wave alliance consortium was createdto focus on the interoperability between Z-Wave devices and today over 400 companies aremembers of the Z-Wave alliance with over 1700 products, all interoperability with each otherproved by a certification process by the Z-Wave alliance [63]. Z-Wave operates in the sub

25

2.7. Z-Wave

Figure 2.13: Network topology of Z-Wave

GHz ISM-bands at 868 MHz in EU and 908MHz in the US which is not as overly crowded asthe 2,4 GHz band that for example WiFi, Bluetooth and ZigBee uses. The Z-Wave networktopology can be seen in Figure 2.13 and defines everything from the radio in the PHY-layerto application specific commands in the Application layer.

Sigma Designs has from the start been the sole chip vendor and the whole Z-Waveprotocol stack has been completely closed where access to the specification only would begranted by purchasing the Z-Wave software development kit and signing a non-disclosureagreement stating that disclosure of inner workings, discussion or other research was notto be published. This situation has caused Z-Wave to not have been as scrutinized as otherprotocols. In 2012 however, Z-Wave started their road to opening up their protocol stackby publishing their lower two stack layers as a standard/recommendation under Interna-tional Telegraph Union Telecommunication Standardization Sector (ITU-T). The resultingstandard/recommendation was ITU-T G.9959 : Short range narrow-band digital radio commu-nication transceivers - PHY, MAC, SAR and LLC layer specifications [26]. In late August 2016Z-Wave released a public specification of their future implementations of Z-Wave. Bundledwith the new public specification came a new security framework called Security 2 (S2) [69]with new security features such as public key Elliptic Curve Diffie Hellman for secure, inband, key exchanges. One other main security feature was supervised commands, where asecured response is required for security critical commands and if a response is not received,the user should be issued a warning that the critical message did not succeed. The S2 frame-work does however only work with the newest Generation 5 chips by Sigma Designs. Olderdevices with chips from the older generation relies on the Security 0 (S0) framework whichis not as safe S2 since key exchange is made in-band in the clear which enables attackers toeavesdrop the exchange. For a network to utilize the new features of S2, all devices on thespecific route that a message takes must be compatible with the S2 framework. If not, thedevices are supposed to fall back to S0 [69].

Security in Z-Wave

Unfortunately, the specifications of S0 has not been published but [17] reverse engineered theprotocol before S2. They managed to find out the frame setup with all fields and payloadsaccording to Figure 2.14, which also was confirmed when the ITU-T G.9959 specification was

26

2.7. Z-Wave

Figure 2.14: Frame setup of a general Z-Wave packet

released. They found out that Z-Wave used AES encryption with three kind of encryptionkeys, network key, frame encryption key and message authentication key. Through analysisof a network key exchange, they found that the network key was not exchanged in clear text,but instead encrypted with a hard coded encryption key consisting of 16 bytes of zeros. Aswith ZigBee, this scenario opens up for attackers to sniff the key exchange packets duringinclusion of new devices since decryption of the key exchange packets would be trivialbecause of the hard coded default key. In the general case when provisioning a new networkkey it is sent with the transmitter in low power mode so that the receiving device has to be inclose proximity to be able to get the message. This, together with the fact that the key is onlysent during pairing or re-pairing makes the attack possible but only during the limited timeframe and within a close proximity to the paired device.

Fouladi et al. in [17] also found that Z-Wave used AES encryption in either CFB or OFBmode for frame encryption since the encrypted messages could be variable length, i.e. notpadded to fill a whole 128 bit block. They later confirmed that it was the OFB mode that wasbeing used together with a 16 byte IV, where byte 0-7 was set by the chips pseudo randomgenerator and bytes 7-15 was set to a nonce value received from the destination node toprovide message freshness.

The key used for encryption was derived by encrypting a hard coded 128 bit frameencryption key in AES ECB mode with the network key as encryption key. For the authen-tication key, the same procedure was performed by encrypting another hard coded 128 bitencryption key with AES-ECB with the network key as encryption key. With this informa-tion, the researchers created a tool called Z-Force that was able to craft its own frame and wasable to send them to a door lock. They managed to find a flaw in the implemented door lockkey exchange mechanism where they sent a key exchange start message but the instance ofthe door lock firmware did not check if the door lock already had been included in a networkand thus began the inclusion in the new network where the researchers later could sendcommands to open up the door. This was later found to be an implementation fault madeby the vendor of that specific lock and not a flaw of the original protocol. This security flawpersisted through the Z-Wave certification process. When the Z-wave alliance was notifiedof this flaw, they added test cases for their certification process to further notice future caseslike this so devices with this flaw would not be certified in the future [16].

To comply with the S2 framework a set of commands needs to be implemented to ex-change keys and authenticate devices/controllers. There are four classes of security that canbe achieved with the new S2 command classes. Each class can have different Network keysso that if one class Network key is compromised, the other classes will not be affected [69].The listed classes are:

27

2.7. Z-Wave

• S2 Access Control:This class opens up for a user to control the public key shared when performing theECDH secret exchange. If a device supports input in the form of digits, letters or othercharacters, the user can enter it to both the device and controller when an inclusion is tobe made. This is a way to control and transport part of the public key made to extract ashared secret in an out of band channel that a potential attacker can not control.

• S2 Authenticated:This class opens up for a user to read part of, or the whole, public key used whenperforming the ECDH secret exchange. The public key could either be printed as a QRcode on the device, or presented on a display on the device. This is also a way to makesure that the intended public key is sent correctly and that no attacker acts as a MITMsince the attacker would have to guess the part of the public key that is transportedout-of-band.

• S2 Unauthenticated:When the device neither has any type of input or a way to present data to the userwith a display or printed QR code, the device may exchange a secret using ECDH. Thishowever opens up for a MITM attack since the public key sent and received from thecontroller is not in any way authenticated.

• S0: This is the fallback security class, Security 0, when a device does not support the S2commands, which is the case for all devices using older than generation 5 chips. Thisclass is therefore only there for interoperability with legacy devices. The implemen-tation of S0 is in the public specification marked as obsolete and any implementationdetails are not disclosed. However, the work of [17] showed that the key exchange wasdone by encrypting a secret with a hard coded network key that is known to both de-vice, controller and attacker and since much focus in the Z-Wave specification lies onbackwards compatibility and interoperability, it can be assumed that the S0 implemen-tation is as [17] describes it.

Devices that fall under the S2 Access control class are mainly devices that control accessto physical places or handles other critical systems. Example of such devices are door locksand garage door openers.

Devices that fall under the S2 Authenticated class are mainly devices that control or mon-itors environments that is not as critical as the devices using S2 Access control. Example ofsuch devices can be alarm systems with various sensors such as motion or door/windowsensors.

Lighting and lighting controllers can also fall under both S2 Authenticated and S2Unauthenticated depending on the security requirements on the lighting system. Worthconsidering however is that if any of the S2 Authenticated or S2 Access Control classes areto be used, each device must be setup independently with an unique Device Specific Key(DSK), explained in the coming paragraph, and an independent label. This can add cost tothe device which might not be justified for many of the applications that devices are used for.

In the ECDH key exchange Z-Wave uses the Curve25519 which is designed to be usedwith 256 bit keys and provides corresponding 128 bit of security. In the Z-Wave specificationthey have further defined the previously mentioned DSK which is the first 16 bytes of the32 byte, 256 bit, ECDH public key. When using S2 Access Control or S2 Authenticated, thejoining device must be able to show the user its DSK or part of its DSK through either adisplay on the device or on a printed label with its DSK which can be represented as a QR-code, for quick scanning of the code with i.e. a smart phone, or simply just the DSK in digitformat. If less security is needed, only the first two bytes of the DSK can be authenticatedwhich means that only 5 digits needs to be entered to the controller as authentication of

28

2.7. Z-Wave

the received public key. Depending on how much of the DSK is entered to the controller, thenode which holds the DSK masks out the part transported out of band with zeros so when thecontroller receives the public key of the node only the last part is received and the controllerthen constructs the complete public key and fill the blank zeros with the information providedby the out of band part of the DSK that the user provided. It is however theoretically possiblefor an attacker to guess the masked out pin-code in 216 (65 536) tries. The security in thissolution however is not to keep the public key secret, but to authenticate that the public keyused is in fact the public key belonging to the node the user wants to include. The public keyis after all meant to be sent in public and the shared secret between the node and the controllershould only be able to be constructed when exchanging their public keys and applying theirrespective secret keys.

To further increase the security, the device has to be interacted with physically, i.e. press-ing a hardware button or remove and reinserting batteries, to be able to start a networkinclusion and key exchange process. The controller also must use unique ECDH key-pairsfor each device it wants to include so that each key exchange is unique.

For replay protection Z-Wave uses what they call Pre-Agreed Nonces (PAN) as either sin-gle cast PAN for messages exchanged between a node pair or multicast PAN for messagesexchanged in a multicast group. The PANs should be stored in a table together with a cor-responding device or group and when a message is sent to or from a device, the state ofthe PAN should be updated to a new state so that the ciphertext of each type of message beindistinguishable from another type for an attacker which cannot decrypt it.

If a PAN entry does not exist when a device wants to send a message, a Nonce Get com-mand should be sent and a Nonce Report should be returned with a new nonce thus syn-chronizing the state of the PAN entry. For each message, a new nonce should be generated bycalling a Next Nonce function which creates a new pseudo random nonce with AES in Countermode Deterministic Random Byte Generator as pseudo random generator. Both the senderand receiver should be in sync with this nonce but since all messages are not guaranteed to bereceived due to being sent wirelessly and possibly in a noisy environment, a receiver mightbecome off sync with the transmitting node. The receiving node can try to decrypt a messagewith up to five future nonces and if none of those five nonces work, a resynchronization ofthe PAN state is needed.

There is a potential risk that an attacker can jam the signal on the receiving device andrecord the signal to later replay it since the receiving end cannot distinguish a replayed mes-sage if the PAN state has not been updated since the jammed messaged was sent. Therefore,if the application is security critical e.g. unlocking or locking a door, the sender can issuea supervised command which will issue a warning to the user if the message was not ac-knowledged by the receiving device. The acknowledge also makes sure that the PAN state issynchronized and that future attempts to replay the unlock message will not be accepted [69].

Routing in Z-Wave

In Z-Wave, devices are grouped as either a controller or a slave.The controller is responsible for network management, network maintenance such as in-

clusion/exclusion of nodes. The controller should also be the device that has informationabout the network topology and store a routing table of which nodes that can communicatewith each other.

A slave is any other node in the network that does not do network management or main-tenance. A slave can either be battery powered or powered by a permanent energy source.If powered by a permanent energy source it will count as an always listening slave and willthen also become a routing node which can relay messages in the network. Battery powereddevices on the other hand is not always listening since they spend time in sleep mode to pre-

29

2.7. Z-Wave

serve energy. Due to this, the battery powered slaves are not intended to be relay nodes andand are not used in that capacity.

For routing, Z-Wave uses a variant of Dynamic Source Routing where the complete pathis sent with a packet that needs routing. When sending a packet, a device should howeverfirst try to reach the destination node directly. If that fails, it should try the last working route.When a device is a repeater, the device holds a copy of the network topology routing tableand can hence calculate a route of maximum length of four hops. If the topology routing tableis outdated and the last working route did not work, the device can either send a networkexplore frame which broadcasts frames over the network to find the destination node andthen backtracks the route to it, or the repeater can request an updated version of the routingtable from the controller.

Possible Attacks on Z-Wave

Since the old specification of Z-Wave is not available publicly, and the new specification is asnew as it is, no published reports of attacks on Z-Wave could be found, however, theoreticallythe system can be attacked.

Encryption key extraction/eavesdropping- attack

If using S0 or the older specification, the system is open for encryption key eavesdroppingwhere a present attacking node could listen in when a node is to be included into the network.However, most of the Z-Wave controllers only allow new nodes to be added upon user inputand only for a limited time. The controller also many times support the key exchange to bedone with limited transmitter power such that the included device has to be within a meterto be able to receive the encryption key. For safe key exchange, S0 should not be used, butinstead the more secure S2 with authenticated public key.

Man in the middle

As with ZigBee, when using the S0 security class, Z-Wave is indirectly vulnerable to a MITMattack since it is vulnerable to encryption key extraction/eavesdropping attacks. When usingthe S2 specification, the system could be vulnerable to MITM attacks if not authenticatingthe public key. An attacker could forge the public key of a node and act as a MITM if thepublic key is not verified. This can thus be avoided if part of, or the complete public key isauthenticated, i.e. using S2 AUTH or S2 AC.

Replay/Playback- attack

If not using supervised commands that requires the device to answer to ensure the nonces insynchronization, an attacker could interfere with a message so it is not delivered, it can laterreplay it as if it was sent the first time. So to protect oneself from replay/playback attacks,the supervised commands should be used.

Denial of service/sleep

Since Z-Wave is a wireless protocol, the same threat exists as for the other wireless protocolsas goes for denial of service and sleep. An attacker could occupy the radio spectrum so notraffic could take place and also making a node that wants to send messages retry until itsenergy recourses are depleted.

Routing attacks

Since the Z-Wave protocol specification is as fresh as it is, no research have been found onattacks on the routing in Z-Wave. However, since the routing protocol is built upon the

30

2.7. Z-Wave

DSR, attacks on DSR have been studied and is presented beneath. Since routing attacks areinsider attacks, the attack scenarios assumes a malicious node being included in the networkit attacks.

Selective Forwarding & Sinkhole

As mentioned, no results for attacks performed on the Z-Wave protocol was found duringthe study. Instead research was performed on the DSR routing protocol instead. Blackholeattacks, a combination of selective forwarding and sinkhole attacks, on DSR have been suc-cessfully executed in [46] and [41] with results that throughput, end-to-end delay and packetdelivery ratio was affected negatively.

Wormhole

Wormhole attacks on DSR have been studied and the attack has been performed and shownto affect the routing in [2] and [49]. End-to-end delay, packet delivery ratio and throughputwas all affected negatively.

Hello flood

A hello flood attack, in the meaning of initiating route-discovery process repeatedly is some-thing that can be done by an attacker if in the network. When initiating a route-discoveryprocess, route-explorer frames are sent through the network which generates a lot of traf-fic. Those explorer frames are then sent to the controller which fills in the routing table so itknows the routes to every node in the network. A malicious attacker could therefore repeat-edly send route-explorer frames so that all other nodes in the network does the same.

Vulnerabilities in Z-Wave- conclusion

Table 2.6: table with different Z-Wave versions and if the version is considered vulnerabledue to lack of implemented security measures.

Attack\ Z-Wave- Z-Wave- Z-Wave- Z-Wave-Protocol Security Class S0 S2 UA S2 AUTH S2 ACMITM Yes Yes* No NoKey extraction/ Yes Yes* No NoEavesdroppingReplay/Playback/Delay No No No NoDenial of Service Yes Yes Yes YesDenial of Sleep Yes Yes Yes YesRouting

- Selective Forwarding Yes Yes Yes Yes- Sinkhole Yes Yes Yes Yes- Wormhole Yes Yes Yes Yes- Hello flood Yes Yes Yes Yes

Yes Directly vulnerableYes* Vulnerable under specific circumstancesNo Native build in SecurityNo* Opt in security availableNA Not applicable to this protocol

31

2.8. Intrusion Detection Systems

2.8 Intrusion Detection Systems

One way to detect a network under attack is by using an intrusion detection system. An IDSwill during runtime gather and analyze data in the network with the objective of detectingabnormal behavior. There are three core intrusion detection concepts.

Signature Detection matches data patterns to known attack characteristics and flags whena behavior is matching a known attack pattern. Signature Detection is thus less likely tosuccessfully detect attacks that it has not been specifically trained for.

Anomaly Detection tries to identify when system behavior is out of the ordinary. The sys-tem behavior is compared to profiles of normal network behavior that the IDS has learnedthrough training. Any significant deviations from the profiles should be flagged, whichmeans previously unknown attacks can be detected at the cost of a high risk of false posi-tives.

Specification-based detection specifies correct behavior of critical objects manually. The cor-rect behavior model is compared to the actual behavior. As most malicious attacks requirea device to change its behavior in some way it is effective at detecting malicious activity butnot understand it.

Much research have been performed on IDS’s and how to detect and mitigate attackson many different network protocols. In this thesis however, it was chosen to only furtherinvestigate IDS’s implemented to detect attacks on AODV networks to see which techniquescould be used to detect attackers in a network and prevent them from doing harm.

An IDS for IoT wireless networks can be either host based or network based. Host basedIDS’s is placed on each node in the network and analyses only the information it can hear inits neighborhood. Network based IDS’s monitors all network traffic of the complete network.This requires that the IDS can gather information of all network activity in the complete net-work

Network Based

One network based IDS was developed by Tseng et al. [61], where distributed network mon-itors were placed to cover the complete network. This made it possible to monitor all theactivity in the network. The detection was specification based where all the monitor nodescooperatively analyzed the traffic so that it followed the specification of the AODV protocoli.e. the hop count, RREQ ID and sequence numbers should be correct for the route messages.This solution relied on the monitors being able to communicate with each other on a separatenetwork to exchange the information it received from the network it monitors. This solutionhas both major pros and cons. It is good because it can gather the complete status of the net-work and will therefore be able to verify any inconsistencies that an attacker may introduceand the results from their tests showed that the IDS was able to detect the attacks specifiedby their specifications. The bad part with a solution like this is that there is a need for acomplete, separate network with nodes covering all other nodes of the network to monitor.This introduces an extra cost of extra hardware and since the network is wireless, coveragemight not always be guaranteed because of interferences. Also, the separate network that themonitors communicate on must be secured so an attacker cannot send forged data there tocover up the attack on the actual network. This adds complexity to the setup and focus onsecuring the original network could instead have been made.

Raza et al. [55], developed a network based IDS on the RPL routing protocol using acentral node that gathered information about the routes and their ranks in the network. Thecentral node continuously sent requests to all nodes in the network for their route ranks tobe able to reconstruct the routing graph. When the complete graph could be reconstructed,inconsistencies could be noticed and the attacking nodes could be detected. They analyzedthe IDS both in a lossless and lossy network environment. The lossless environment guar-anteed that the messages sent between nodes being in range of each other being delivered

32

2.8. Intrusion Detection Systems

all the time, i.e. no interference. The lossy environment however mimics the real world byintroducing interference between nodes so all messages sent do not always get received byall nodes even though they were in range. The IDS proved to be effective and detected almostall attacks performed, but did also get a few false positives.

Host Based

With a host based IDS solution, the IDS is placed on each node in the network, and each nodeperforms analysis and detection on its own. The functionality can be extended further if thenodes can communicate data to analyze between each other as well. This however, if notsecured properly with for example encryption, opens up for an attacker to spoof as well socareful consideration has to be done about what information is sent between the nodes.

One example of a decentralized IDS was developed by Marti. et al. [45], but for thedynamic source routing protocol. The technique used is a local watchdog that watches andanalyzes the traffic in the neighborhood. One feature of DSR is that the complete route issent with each data message. This opens up for nodes verifying that when a node has sent amessage, it can verify that the next node on the route sends it further on to the correct nextnode. This is done by the node sending the message, leaving its radio on to listen to the radiomedium until it has received the message from the node it expects to forward the message.The node can then verify that the message received was sent as expected. This techniquerelies on each link being bidirectional, i.e. both nodes can send and receive messages betweeneach other reliably. This does however become a problem when the network is placed in aenvironment with large interferences since messages sometimes will be received properlybecause of the interference and nodes can be falsely reported as malicious nodes. This IDSwas developed for DSR, but the same technique could be implemented in AODV as well.

For example, da Silva et al. [60], implemented a host based IDS for AODV to detect rout-ing attacks. They did however use hardware with more resources than many times availablein common IoT nodes. Their detection was built upon saving all received messages from theneighborhood in a message buffer ranging from 30 to 400 messages. Since memory is a con-straint in many IoT nodes, the solution might not be suitable for applications with nodes thathas constrained hardware resources.

Parker et al. [28] also implemented a host based IDS for AODV over IPv6 but did alsohave unlimited hardware recourses. With their IDS, they managed to notice inconsistencies ofrouting messages and they did notice when packages was dropped. Since they did their testson PCs instead of embedded, hardware constrained platforms, they could save large amountof messages and analyze the content very fast without the risk of missing more incomingmessages, a scenario that might not be guaranteed with constrained IoT devices.

Prevention of attacks using an IDS

An IDS could be used to both detect attacks and prevent them from continue to being exe-cuted. To prevent an attacker to continue its attack when detected, the most efficient way isto simply ignore that node. All future traffic coming from that node will then not have anyimpact on the network, more than it occupying the radio medium. For legit nodes to knowwhat malicious nodes exist, a blacklist could be used. Then all found malicious nodes couldbe blacklisted. When future packets then arrive from a malicious node, the receiving nodewill check if that node ID or address exists in the blacklist, and if so, it will ignore it. Thisdoes however presume that the malicious node cannot acquire or spoof a new ID or addressor that the spoof can be detected.

When a malicious node has been detected and blacklisted, there still might exist routeswith that malicious node in them. For the network to be able to be restored, those routesneeds to be deleted. When using AODV, the blacklisting node could send out a RERR mes-sage that a route with a specific sequence number should be purged. Then all routes with

33

2.9. Contiki

that number will be deleted. However, routes to the blacklisted node might still exist in othernodes routing tables. The nodes that has routes to the malicious node thus need to get infor-mation about a node being blacklisted. One way to do this is to send messages to the nodesin the network that it found a malicious node, but that also opens up for a malicious node tosend the same messages about another node, resulting in blacklisting legit nodes [37, 45].

Sybil and spoofed ID detection

As previously mentioned a node that can simply change its ID and reenter the network afterbeing blacklisted wont be stopped by a black hole detection only. There needs to be a way todiscard any messages from the blacklisted node whatever ID it chooses after detection, dueto the fact that the malicious attacker will hear the messages about it being blacklisted andsimply switch ID. With the simple approach of white listing legit nodes on startup the ID’sthat the sybil attacker may use is limited to the other nodes present in the network whichmay get them blacklisted one after another until no nodes are trusted, as the stolen identitywill be regarded as an attacker and thus the actual node will be blamed for what the sybilnode is up to [27].

2.9 Contiki

Contiki [7] is an open source, real time operating system (OS) for hardware constrained de-vices suitable for IoT written in C. The OS provides features such as multitasking, networkingthrough IPv4/IPv6 or a self developed, lightweight communication stack called Rime, andwireless communication over IEEE 802.15.4. The OS can run on hardware with about 10kbof RAM and about 30kb of program memory. With the OS comes a simulator called Coojawhich can be used to test the OS on a PC without the need for real hardware.

The Contiki network model is divided into seven different layers.

• PHY, Physical radio interface. Defines how communication between nodes should besent over the air. Contiki supports full IEEE 802.15.4 radio communication.

• Framer. This layer defies how a packet should be sent over the air. The included framersin Contiki is 802.15.14-framer which creates 802.15.4 compatible frames, and no-framerwhich only outputs raw packet data.

• RDC, Radio duty cycling. This layer handles how the radio should sleep and be awake.By making the radio sleep, energy can be preserved and battery life can be extendedvastly. There are several implemented RDC protocols included in Contiki. There arethree RDC protocols which , there’s three RDCs that do not save any energy by makingthe radio sleep [8]. They are:

– NullRDC-noframer which does not use any framer function but only forwardsreceived raw data from the radio to upper layers.

– NullRDC which uses a chosen framer to create and parse headers of receivedframes. The nullrdc only acts as a pass through layer for received frames andonly reports the results of transmitted and received packets, such as collisions andsuccessful transmissions.

– SICSlowMAC is a RDC that uses IEEE 802.15.4 frames.

The energysaving RDCs are:

– X-MAC is a sleepy asynchronous protocol that uses a strobed (repeated) preamblewith target address information when transmitting that makes sleeping nodes beable to notice when a frame is being transmitted by periodically wake up to re-ceive the transmitted preamble. When a receiving node wakes up and receives a

34

2.9. Contiki

preamble meant for itself, it sends an acknowledge frame to let the transmittingnode know it is awake and listening.

– CX-MAC (Compatibility X-MAC) is based on X-MAC but has more relaxed timingrequirements compared to X-MAC.

– ContikiMAC is an enhancement over the X-MAC where it strobes the packagesuntil the receiving node responds with an acknowledge frame. This is the defaultRDC in Contiki and is tailored for 802.15.4 frames together with the TI-CC2420transceiver. The ContikiMAC protocol provides good energy efficiency comparedto the other RDCs [10].

– LPP (Low-Power Probing) is a RDC protocol where each node transmits probeswith and a node that wants to transmit to another node waits for a probe from thereceiving node to know it is awake to be able to send its packet.

• MAC, Medium Access Control. There are two MAC-protocols present in Contiki, car-rier sense multiple access (CSMA) and NullMAC. The CSMA MAC is used to sense theradio medium before starting to send frames and also handles retransmission if therewas a collision. The NullMAC simply just forwards packages to the radio and does notcheck for collisions or if the medium is free.

• Network Contiki has support for three network stacks, uIP with support for IPv4, afull featured IPv6 stack and its self developed stack called Rime. As for routing in thedifferent stacks, uIP and the IPv6 stack uses RPL, and the Rime stack uses a lightweightversion of AODV.

• Application. The application layer is the highest layer and with help from the lowerlayers, nodes can serve different applications wirelessly.

Rime

Rime is a lightweight, adaptive network stack made for wireless sensor networks that canrun over 802.15.4. The core in Rime lies in an architecture called Chameleon. Chameleon wasdeveloped with three purposes in mind,

• It should simplify the implementation of sensor network communication protocolswhich is done with the Rime stack.

• It should be able to implement the architecture on top of already existing MAC andlink-layer protocols. This is achieved thanks to using packet attributes instead of packetheaders.

• It should allow for packet headers to be formed independently of application or proto-cols that is running inside the stack.

The chameleon header transformation modules can be constructed so that it is either bit-packed, where only the amount of bits really necessary is used, e.g if a number will not belarger than 16, then the bit-packed header will only use 4 bits instead of 8,16 or 32 dependingon CPU-architecture, thus saving several bits that needs to be transmitted and saving energy.The transformation module can also be constructed so it conforms to other MAC or com-munication protocols [9]. For Chameleon to know what attributes to use for which kind ofpacket, it operates using logical channels much like TCP/UPD uses ports. For each channel,a set of attributes is provided. When a packet needs to be transformed it will be accordingto that set of attributes. Since every attribute can be set to a specific size, the number of bitsand number of attributes to be sent can be optimized for the specific application saving bothenergy and time.

35

2.9. Contiki

Figure 2.15: The communication primitives in Rime and how they are related to each other.

By using different Chameleon channels it is also possible to re-use different communica-tion primitives. An application can have several modules instantiated on different channels.The primitives implemented and how they relate is shown in Figure 2.15 and are:

• Anonymous Broadcast (ABC), broadcast to neighbor nodes only with no informationabout who sent the frame. Additional attributes: None.

• Identified Broadcast (BC), the same as ABC but with a packet attribute telling who wasthe sender. Additional attributes: Sender.

• Polite/Identified Polite (IPolite best effort local broadcast) The Polite/IPolite is usedunder NF and acts as a way to reduce the amount of packages sent in a local neigh-borhood with the same header information. The Polite/IPolite makes sure that only acertain amount the same broadcast messages are sent in the neighborhood. Additionalattributes: None

• Netflood (NF), is used when a node wants to send a BC message and wants it to reachthe complete network. To avoid redundant transmissions and routing loops , i.e. thenode if the node hears its own packet it should not retransmit, the netflood primitivekeeps track of the packet it sent and if received again, it stops retransmitting the packetfurther. Additional attributes: End-to-End Sender (E-Sender), Hops, End-to-End-Packet-ID(E-PacketID).

• Unicast (UC), uses the BC primitive to send unicast messages to a neighbor specificnode and thus has to add a Receiver packet attribute to its transmitted packet. Additionalattributes: Receiver.

• Multihop (MH), is used when a node wants to send a message to a node that is not aneighbor, but has to be resent by at least one neighbor. Multihop uses UC and it is upto the above routing protocol to handle how the routing should be done and what nodeis the next hop. Additional attributes: E-Sender, E-Receiver, Hops.

• Stubborn Unicast (STUC) is used to repeatedly send a packet to a single hop neighborthrough the UC primitive. It continues to send until an upper communication primi-tive cancels it. The STUC primitive is mainly used by the Reliable Unicast primitive.Additional attributes: None.

36

2.9. Contiki

Figure 2.16: An example of two applications running using Rime. One uses a mesh routingprotocol while the other communicates with neighboring nodes only.

• Reliable Unicast (RUC), is used to reliably send a unicast packet to a single hop neigh-bor. The RUC primitive uses acknowledge packets and retransmissions to make surethat the neighbor to send to receives the intended packet. Additional attributes: Packet-Type, Packet-ID.

• Reliable Multihop (RMH), is used to reliably send multihop packages in the network.It uses the RUC primitive to make sure packages are delivered properly. Additionalattributes: E-Sender, E-Receiver, Time-to-Live (TTL), Max-retransmit (Max-Rexmit).

An example of an application setup using Rime can be found in Figure 2.16 where one ap-plication uses the built in mesh routing protocol and one application communicated directlywith neighboring nodes. As can be seen in the Figure, each channel is being used by a set ofcommunication primitives and each primitive adds its additional packet attributes that thechannel will use to craft frames [51].

Mesh routing in Rime

The mesh routing module in Contiki can be visualized in Figure 2.16 as being used by Appli-cation 1. The mesh routing is based on the AODV routing protocol but is not fully featured.The mesh routing in Rime for instance does not support RERR messages, and a route replymessage should only be sent from the destined node. Sequence numbers for routes does notexist as well which results in nodes not knowing if fresher routes exists than the one itself hasand when not to update routes.

When a node wants to send a packet to another node it tries to send it through the Mul-tihop primitive. If the node does not already have a route setup to a next hop neighbor, itinitiates a route-discovery process (route-setup in Figure 2.16). The route-discovery processstarts with the node flooding RREQ messages using the Netflood primitive. This floods thenetwork with RREQs that contains the node id to the node that a route is requested for. Withthe RREQ message is also a RREQ-ID to help receiving nodes know if the RREQ already hasbeen retransmitted or if it should be. When a node receives a packet with destination to itselfit should reply with a RREP message to the neighbor who sent the RREQ. The RREP messagecontains RREQ-ID, number of hops, destination and originator. The neighboring node then

37

2.9. Contiki

receives the RREP and forwards it to the neighbor it received the RREQ from and adds oneto the hop count until the RREP reaches the node who initiated the RREQ. This way, all thenodes in along the path knows who will be the next hop neighbor to send to along a path.

When a RREP has reached the node who requested a route to another node, the Multihopprimitive is called and the data packet that initially were to be sent will be dequeued and sentto its next hop neighbor who will forward it further on until it reaches its destination.

Cooja

Contiki is shipped with a fully featured simulator called Cooja. Cooja is able to simulate thehardware of a number of motes including the radio and how the motes send packaged wire-lessly. It supports five different wireless mediums but only Unit Disk Graph Medium will behandled in this thesis. Unit Disk Graph Medium (UDGM): Distance Loss is a medium whichchanges the transmission distance with regard to transmission power. With this medium it ispossible to change transmission range, transmission/reception success rate and has built inlossy support to mimic a lossy network environment. UDGM models the transmission rangeas a circular disc around each node, and all nodes that is within that disc is considered to bein range of that node. Cooja also has a support for log messages being logged in a commonlog for future analysis of what was going on at each node.

38

3 Method

3.1 Literature study

The Online Search Process, as described in [50], is a five step iterative process.

• Identify search terms

• Limit the search

• Truncation, wildcards, and phrases

• Combining terms 1 (Boolean logic)

• Combining terms 2 (using other connectors)

For the first step four Concepts were chosen to stand as base for finding the search terms.The concepts chosen were Security, IoT, Procol Stack, and attacks. These concepts were putin a two-dimensional matrix in such a way that for each concept there were four things toidentify; synonyms, broader terms, restricting terms, related terms, and alternative spellings.To increase the likelihood of collecting decent IoT-related search terms for the first iteration,taxonomies on IoT-related security were quickly investigated, choosing keywords related tosecurity and thus quickly filling up the list of things and possible combinations that neededto be investigated further. The security specifications of the protocol stacks also providedvaluable information but also keywords to use in the continued search. Due to familiarity forthe authors mostly IEEE, Google Scholar, and ACM was used for gathering information, butScienceDirect, SpringerLink, and Web of Science was also used.

To limit the search space, the focus of the search was decided to be gathering informationabout common attack vectors against the chosen IoT-protocols and less about specific ideasand previous attacks. Security concepts narrower terms also needed an introduction whichlead to them not being sorted out as well as the CIA-triangle.

The first wave of search was created by combining phrases by selecting a protocol and anattack, or by combining IoT related words with attacks. As such two queries could be

• "Zigbee" AND ("Denial of Service" OR "Denial of sleep" OR "dos")

39

3.2. Intrusion Detection System in practice

• (IoT OR "Internet of things" OR WSN OR WoT OR "Web of Things") AND ("Man /2Middle" OR MitM)

These combinations were used for the search and evaluated to create the evaluation partof the report, and provide insight and inspiration for the second, IDS, part. During the searchsome keywords were added when they were stumbled upon and some were found to berarely used. In the end no formal return to step one was attempted but as keywords emergedalready used queries were updated and searched for again.

3.2 Intrusion Detection System in practice

As can be found in the conclusion of the first part of this thesis, the chances of a maliciousnode gaining access to an encrypted network are hard to mitigate due to the limited resourceson the nodes. Since it obviously has been hard to safely provision encryption keys securelyand the complexity end-to-end encryption adds, the scenario that will further be consideredis a network of nodes where the network encryption key has been compromised and that oneor many malicious node will be present. The lack of end-to-end encryption makes it hard toverify the authenticity of data packets sent in the network which motivates a way to verifythat data sent in the network is legit and as expected.

Therefore there is a need for an IDS to detect malicious nodes performing routing attackson such network. The practical implementation of this thesis will thus focus on implement-ing such IDS. The IDS will be implemented in Contiki and simulated in the Cooja simulator,much like the IDS implemented by Raza et al. [55] called SVELTE. The metrics and evalu-ation will also be as similar to SVELTE, since the results presented for SVELTE was consid-ered good. SVELTE was implemented to detect spoofed or altered information, sinkhole andSelective forwarding attacks and achieved results of up to 100% true detection rates whenusing lossless networks and 70-90% true positive detection when using lossy networks (net-works where messages are not guaranteed to be delivered, more ingoing information aboutlossy/lossless networks will be found in section 3.3). SVELTE was implemented to detectthose attacks on a 6LowPAN network with the uIP stack and the RPL routing protocol. InContiki however, there exists one more network stack called Rime. Rime is a lightweightcommunication stack with a lightweight version of AODV for mesh routing protocol. Theaim with this implementation was thus to find out if it was possible to implement an IDS thatperformed likewise with SVELTE implemented on the Rime stack. The experiment setup andevaluation will therefore be close to the setup in SVELTE, with some slight modifications. TheIDS will be tested on three network sizes, 8, 16 and 32 nodes. It will be tested using losslessand lossy environments and the simulation will go on for 30 minutes. The simulation willbe carried out in the Cooja simulator and the network will consist of T-Mote SKY nodes, thesame as SVELTE was evaluated with. The only difference between SVELTE and the evalua-tion of the IDS implemented in this thesis is that SVELTE was evaluated after 5, 10, 20 and 30minutes to see how the metrics was affected by the time that it was run. The IDS in this thesiswas evaluated after the full 30 minutes.

To further improve the security of the network, the IDS implemented in this thesis alsofeatures a sybil detection technique, which in SVELTE was not present making their IDSvulnerable and open for sybil and spoofed ID attacks.

Attacks

The network topology investigated is a mesh network running in Contiki. The attacks toinvestigate are connected to routing attacks due to the effects a malicious node can have onthe network traffic. The first attack is the sinkhole attack, where the malicious node falselycommunicates that it has a very good route to a destined node. When the malicious nodehas forged the route to the destination, if that route is considered to be the best available, all

40

3.2. Intrusion Detection System in practice

future traffic to that destination node will be directed through the malicious node. It is thenup to the malicious node to do what it wants with the upcoming directed traffic. It can eitherjust forward the traffic according to the normal protocol, or it can strengthen the attack byeither altering the data to forward, or choose not to forward the packet at all, the latter beinga Selective forwarding attack. When combining a sinkhole attack with selective forwardingit becomes a Black-hole attack. One way to mitigate a Black hole attack is to check if thelink between two nodes are bi-directional, but because the lack of end-to-end encryption, theBlack hole node could easily forge the behavior of the destination node by acting as being thatnode. This behavior, by impersonating another node, can be classified as a sybil attack whichwhen combined with a Black hole attack makes up for a strong attack on a mesh network.

Sinkhole

The sinkhole attack can be implemented in a few different ways. The core idea behind it is tomake the malicious node seem like the best choice to choose as route towards any other node.That can be achieved by not following the routing protocol and forge or alter information inthe routing messages. In Contiki running Rime with its mesh-routing, the sinkhole attackcan be implemented in at least two different ways. Either by altering routing informationin received RREP or RREQ messages or by replying with a forged RREP when receiving aRREQ.

1. Altering RREQ or RREP: When a sinkhole node receives a RREQ or RREP from anothernode, it can alter the hop count information included in the routing message. The stan-dard protocol states that the node receiving a RREQ or RREP message should add oneto the hop count but if the receiving node were to be a sinkhole node, it can alter thehop count to being one, thus making other nodes think that the sinkhole node have thedestined node as a direct neighbor resulting in it seem having a very good route to it.With this implementation, the node will have an actual route to the node requesting theroute and will most likely receive RREPs from the destination to be part of the routeeven though there might be better routes available.

2. Forging RREP: When a sinkhole node receives a RREQ message from another node,it could instead of forward that RREQ further on into the network, forge that it hasreceived a RREP message from the destined node resulting in the surrounding nodesthinking it being a direct neighbor with the destination node. With this implementationthe node will not always get a real route, or a suboptimal route to the destination andcan therefore only drop received packages.

The effect of this attack will be that all nodes that are the neighbors of a sinkhole node willthink that it has good routes to many of the nodes in the network. This can disrupt the trafficin the network in such way the the payload delivery rate declines.

Black-hole

The Black-hole attack can be implemented by first executing a sinkhole attack to attract trafficthrough itself. Then when the data packets starts coming via the malicious node, it can chooseto either only forward some packets or none at all depending on the aim of the attack.

Sybil

Where the sinkhole attacks modifies hop counts and forges RREP, the sybil works with itsidentity. Switching identity is done to confuse nodes, mask malicious behavior, waste re-sources, or taking over trust based systems. In Rime the attack can be carried out by mod-ifying the packet attribute Sender. A malicious node creating sybil identities can either steal

41

3.2. Intrusion Detection System in practice

Figure 3.1: Architecture of the IDS implemented using RIME in Contiki.

an already existing identity, which is easier if the benign node is in some way hindered fromparticipating in the network, or by making new identities up.

Intrusion Detection System implementation

To identify and mitigate a possible malicious node in the network, an IDS has been developed.With the IDS comes support for detection of sinkhole attacks, selective forwarding, black-hole attacks and sybil attacks. This IDS is implemented as shown in figure 3.1 with twoextra communication channels. Channel 138 is used for sharing information about receivedsignal strength indicator (RSSI) of different packages that the IDS uses for sybil detection andchannel 139 is used to alert surrounding nodes that a malicious node has been found and thatthe surrounding nodes should blacklist that malicious nodes ID.

Detection Technique

The IDS has been implemented in a host based, distributed way, much like the IDS by daSilva et al. [60], such that it does not only monitor and analyzes messages that itself havesent but, if possible, also monitor messages its neighbors are sending and verifying that theneighboring nodes behave. However, [60] used a much larger message queue for its analysison each node in their IDS. Because the IDS developed in this thesis has very constrainedhardware resources, only one message of each type will be saved for analysis.

This detection technique requires that every node cannot spoof or alter its IDs or addressessince if that was possible, it could spoof another node in the network and then perform anattack. This can result in that spoofed ID or address to be reported as malicious while theactual node is really behaving. ID’s or addresses is not something that can be trusted in a realscenario if not using encryption, which this scenario cannot do. Therefore, it is crucial to alsodetect if a malicious node exploits the ability to spoof or alter ID’s or address. This will bedone using a sybil detection module, also implemented in a host based manner, that sendsdata about RSSI of each received packet so further analysis can be performed.To be able to implement the IDS, some conditions have to be met.

42

3.2. Intrusion Detection System in practice

• The radio must be in always listening mode, called promiscuous mode, to be able toreceive messages to save for analysis.

– When using the SKY-motes with the CC2024 radio, address filtering has to beturned off. This is because if address filtering is enabled, the radio will ignore allmessages that are not meant for the node or broadcast messages. This is needed sothe nodes can receive messages not meant for them so it can analyze an verify thatthey are legit.

– When disabling address filtering, automatic, hardware, acknowledgements forunicast messages also gets disabled since the radio will not analyze the receiveraddress. For the CSMA to work with collision avoidance and retransmissions, au-tomatic acknowledgements has to work. Automatic acknowledgements does nothave to be handled by the radio hardware, but can instead be sent as a normalpacket. The automatic acknowledgements can thus be handled by the RDC andMAC in Contiki, but with a result of an increased delay since messages has tobe sent from the radio to the on board processor and back, instead of being han-dled directly on the radio. The choice of RDC, with support for software basedautomatic acknowledgements together with support for always listening, is verylimited in Contiki. The only setup that supports those constraints is the NullRDCRDC. Thanks to this, no energy saving mechanisms can be used such as makingthe micro controller or radio sleep to preserve energy.

• Nodes must know who are their neighbors to be able to know if it is expected to heara relayed message or not. If the nodes do not know who are its neighbors, it cannotdistinguish which messages that it expects to hear being relayed. This situation is calledHidden Node Problem as visualized in 3.2. In the figure, node 1 can hear messages from2 meant for 3 but will not hear any messages from 3. Node 1 cannot thus verify themessages sent from node 3.

• The IDS must have the computing power and memory to save packages sent or receivedto be able to analyze the packages if the received package is as expected. The time tosave and analyze the messages can also not be significantly large since that would resultin the node missing other incoming packets needed for analysis.

• Nodes must be placed statically in their environment. This is needed to make sure thatthe node always knows who are their neighbors. This is also a requirement for the sybildetection, since it learns about the RSSIs from its neighbors, and if the nodes were notto be static, it would think the moving node spoofing node ID’s.

• No nodes are behaving maliciously during initialization of the network. This is becausethe sybil detection needs to learn the expected behavior of the network.

The detection used to identify a sinkhole, selective forwarding or Black-hole-attack issomewhat primitive. Due to the broadcast nature of wireless communication, each messagesent that is expected to be forwarded through the network can be overheard and analyzedwhen relayed even if the node listening is not the intended destination. This property can beutilized to verify that messages are being forwarded and that the information in the messagesare as expected.

For example, when a node sends a data message, it can expect the content of the messagebeing retransmitted exactly as it sent it but with changed next receiver address. If any otherinformation, such as destination address, originator address, or the data payload, then thatnode should be marked as malicious and be excluded from the network and future routes.For example, as shown in Table 3.1, in the black-hole case, when node 2 modifies the hopcount from the expected 2 to 1, node 1 can overhear that when node 2 sends it further tonode 3. Node 1 can then verify what node 2 sent and notice that it did not follow protocol

43

3.2. Intrusion Detection System in practice

Table 3.1: Example of how a data message would be sent in a network with 3 nodes setuplike in Figure 3.2.* Means field modified.- Means packet not sent.

Mode Type Sender Receiver E2E- E2E- Hops Data NodesSender Receiver Hearing

Normal RREQ 1 2 1 3 1 2RREQ 2 3 1 3 2 1,3RREP 3 2 3 1 1 2RREP 2 1 3 1 2 1,3Data 1 2 1 3 1 Hello 2Data 2 3 1 3 2 Hello 1,3

black-hole RREQ 1 2 1 3 1 2malicious RREQ 2 3 1 3 1* 1,3node = 2 RREP 3 2 3 1 1 2

RREP 2 1 3 1 1* 1,3Data 1 2 1 3 1 Hello 2Data - - - - - - 1,3

Figure 3.2: An example of a Hidden Node Problem where node 1 can communicate with node2 and 2 with 3 but node 1 will not hear any messages from 3. Node 1 though, will hear when2 is communicating with 3.

by not adding 1 to the hop count thus making node 2 a sinkhole node. When further onnode 1 has got a route to node 3 and wants to send the data message, node 2 receives it butdecides to not forward it. Node 1 can then notice that as well because if node 2 would haveforwarded it, node 1 would have heard that, resulting in node 1 reporting node 2 as malicious.

Sinkhole Detection

For the sinkhole Detection, the IDS checks according to the following rules:

• A RREP message should be heard being forwarded if the receiver is not the destination.

• A RREP/RREQ message’s hop count should always increase when sent further on.

• A RREP message should only be heard if a RREQ message has first been heard trans-mitted by the node. However, if a route receives a RREP from another route towardsa destination route, and the node has a cached route to that destination, the node willnot initiate a route discovery process with sending out RREQs, but only send the RREP

44

3.2. Intrusion Detection System in practice

further on to its next hop neighbor in that route. Therefore, it is hard to distinguishwhen this scenario is caused by a node actually having a cached route, or a maliciousnode forging a RREP that it has a route.

One way to detect it though would be to try the link for bi directionality, because whena malicious node forges a RREP like this, it will not have a working route to the des-tined node. When a malicious node receives a data packet, it cannot forward it to thedestination due to that it forged it had a route, so either it has to find a route or dropthe package. The IDS can detect dropping of packages, which will be covered later inthe report, so even if it cannot detect the forged RREPs from legit ones, it can detect theeffect of the forged RREP in a later stage. If the node however would spoof an answerfrom the destination node, the sybil detection should be able to notice that and reportthe node as malicious.

A visualization of the IDS state machine can be shown in Figures 3.3 and 3.4.With help of those rules, the IDS monitors the behavior of surrounding nodes. When a

node receives a RREQ that it should forward, it saves the information in that RREQ. Sincethe RREQ protocol is using the Identified-Polite module, all propagated RREQs will be de-layed with up to 1 second, with the effect that all further received RREQs should have itshop count increased. This way, when a node forwards a RREQ, when it hears a new RREQ,the hop count should have increased if the sending node is not a sinkhole node that adver-tises that it has a better route than it has by decreasing the hop count. If the IDS detects thata received RREQ hop count is decreased, it flags the node that sent that RREQ, and after 5reports it is considered a sinkhole node and advertises that to the rest of the network. Sincethe routing information now present in the network relies on false information introducedby the malicious node, and the lightweight AODV implementation does not support purg-ing of a specific route sequence number, all routing information in the network needs to bereset because false routes might have been propagated in nodes route tables. So when a nodeadvertises that a node is malicious, all nodes in the network should blacklist that node IDand flush their routing tables. This is performed using the Netflood primitive which floodsthe network in a way that every node should receive the intended information. This adver-tisement mechanism could however also be exploited by a malicious node to get legit nodesblacklisted. This is a flaw that needs to be considered, but in the scenario evaluated, detectionand prevention is tested with the assumption that a malicious node not attacking the IDS.

When the RREQ messages have propagated into the network such that the destinationnode is reached, it sends a RREP towards the RREQ originator. Before sending the RREP tothe next hop neighbor on the route, it saves the outgoing RREP message so it can analyze therelayed message. When the neighbor has received the RREP it should forward it and whenthat is done, the node initiating the RREP can verify the received RREP with the one itselfsent. If the received hop count has not increased, the node sending the RREP has altered thedata and the node should be flagged. After 5 reports of malicious behavior, the IDS advertisesthat the flagged node is malicious and that it should be blacklisted.

Selective Forwarding Detection

The detection of a selective forwarding node relies on the same principle as with the sinkholedetection. Since messages sent is meant to be forwarded can be heard, a node sending amessage can save that message and check so that it is forwarded and that the forwardedmessage is forwarded as intended. The IDS rules for Selective forwarding is

• A sent message that is meant to be forwarded should be heard relayed within a certaintime, which is set to 10 seconds. If the message is not forwarded within that time thereceiving node should be flagged.

45

3.2. Intrusion Detection System in practice

Figure 3.3: A state machine describing how the IDS processes incoming packets

• A sent message that is meant to be forwarded should not be forwarded unless the mod-ifications is expected, such as changing the receiver of the next hop.

Things to consider here is that a node on the path to a destination might have had its routeremoved or outdated. In that case that node has to initiate a route discovery process whichcan take some time, if a route has not been found in 10 seconds, the node will not have anode to forward the data message to and thus making the surrounding nodes think that itdropped the packet and being flagged as a selective forwarding node. This false positive caseis mitigated by requiring 5 reports to be considered malicious. However, there is no decay onthe reports so when running the network for longer times, the reports will have to be resetfor the network to continue to function properly.

Sybil Detection

To protect against sybil Attacks an RSSI-based approach is proposed. Inspired by the rea-soning by Yang et al. [30], where an implementation of a sybil detection technique uses thequotient of two RSSI-values to remove the transmitter power factor from the result. Themath is described below, where P0 is the current through the transmitter, k some constant andd represents distance.

Ri/Rj = (P0 ˚ k

di)α/(

P0 ˚ kdj

)α

In this implementation each node that receives a data message stores that transmission’sID and the RSSI, and transmits an IDS-package to its neighbors, who then calculate the ratio

46

3.2. Intrusion Detection System in practice

Figure 3.4: A state machine describing how the IDS processes outoging packets

and keeps an online update of the average RSSI-ratio and the standard deviation betweenthose node pairs. There are three types of nodes involved,

• The original sender of the message.

• The reporter who transmits to neighbors about what RSSI it received.

• The receivers, who compare this messages RSSI-ratio to standard.

If the sybil attacker is impersonating another node in the network the difference betweenthe normal case and the attacker transmission should be detected. When the attacker insteadcreates a brand new identity the detection algorithm compares the ratio with the other nodesratio entries to see if they are placed in the same position.

For the first 255 reports between a pair of nodes about a sender, the receiver establishesthe mean quotient between the nodes and the standard deviation. However the system isfunctional after fewer reports.

Figure 3.5 shows a typical distribution of signal ratios between transmissions 100-255 forthis node pair. Figure 3.6 illustrates the distribution of signal ratios in regard to normal for asybil node that attempts to impersonate the previously mentioned node. These distributionswere used to determine the threshold for amount of standard deviations to tolerate beforeconsidering a message illicit.

Sybil Attack

The solution uses only integer numbers but some operations create float points, such as thedivision of the RSSIs which might create stacking rounding errors. If this error is large itcan compromise the correctness of the system. In Figures 3.7a and 3.7b the error is shownin % detailing the difference between the system representation of the average RSSI and onecalculated using Matlab on the same data. To reduce the round off error the numerator was

47

3.2. Intrusion Detection System in practice

Figure 3.5: Data points before attack

Figure 3.6: Data points after attack

multiplied by 100. The standard deviation is calculated and stored according to Welford’smethod and the error in RSSI, which works as in-data, as well as the error error in calculatingstacks and adds up to the error presented in Figures 3.8a and 3.8b.

The distribution of RSSI-points from simulations can be analyzed to set the limit for howmany standard deviations off a transmission can be, and still be considered valid. Using thedata displayed in Figure 3.9 it can be calculated that for instance using the limit 2 standarddeviations has a false positive rate of less than 4%, while using 3 standard deviations wouldresult in 0%. This value varies for different node-pairs which makes it difficult to set a generalvalue.

Using a setup as in Figure 3.10, the sybil node, 5, steals the identity of another node andtries to broadcast as if it was it. Node 5 begins to transmit as if it was node 4 after the sys-tem has been operating normally to calibrate. Most data points during normal operation aredistributed within two standard deviations, as seen in Figure 3.11. When node 5 begins totransmit, most data deviate by more than two standard deviations, Figure 3.12

48

3.2. Intrusion Detection System in practice

(a) (b)

Figure 3.7: Error of system representation of average RSSI in % of two different data sets

(a) (b)

Figure 3.8: Error estimating standard deviations in two different data sets.

Figure 3.9: Common distribution of signal ratios for one node pair in the simulation

49

3.2. Intrusion Detection System in practice

Figure 3.10: Setup for when node 5 steals the identity of node 4.

Figure 3.11: Distributions before attack

50

3.2. Intrusion Detection System in practice

Figure 3.12: Comparing attacking node 5 spoofing ID 4.

51

3.3. Experiment setup

3.3 Experiment setup

The network setup and the evaluation metrics are described in the following sections.

Sinkhole and Selective Forwarding detection

To test how the IDS performs, the system will be simulated in the Cooja simulator that comeswith Contiki. Since the aim is to compare the results of the IDS developed in this thesis withthe IDS used by Raza et al. [55], SVELTE, the experiment setup in this thesis will be as closeas the one used to evaluate SVELTE.

Network setup

There will be three different network setups with 8, 16 and 32 nodes with 1, 2 and 4 maliciousnodes respectively, as shown in Figure 3.13. In each configuration, node 1 is a central nodethat requests data from a random node in the network and waits for a response of from thatnode. Each grid in the figure is 10x10m and each node reaches all other nodes within 50mfrom it.

Lossless and lossy networks

Since the IDS’s placement is in the IoT, it is supposed to work in the real world which is some-what different from the ideal case that a simulation environment can provide. The simulationenvironment can provide lossless network environments such that packages will always bedelivered if two nodes are in range of each other. The real world however exposed to in-terferences and packages might not always be delivered even if two nodes should be withinrange. Therefore, the IDS will be tested both in a lossless network, where packages are alwaysdelivered if two nodes are within range, and with a lossy network model, where packagessometimes will not be received even if two nodes were in range.

The loss model used in the simulations is the same one used by SVELTEs evaluation,which is Cooja’s default radio model, UDGM: Distance loss that models the transmission andreception range as a circular disc around each node.This model has support for interferenceand is used when simulating the lossy networks.

Since the IDS depends on bidirectional links, i.e. if a node can transmit to a neighbor itshould also hear when the neighbor transmits anything. This dependency can thus make theIDS’s performance decrease, at least in the selective forwarding case where the IDS listens

(a) Network topology with 8nodes. Node 1 is source nodeand node 2 is malicious.

(b) Network topology with 16node. Node 1 is source nodeand node 2 and 3 are mali-cious.

(c) Network topology with 16node. Node 1 is source nodeand node 2,3 4 and 5 are mali-cious.

Figure 3.13: The network topologies

52

3.3. Experiment setup

for a relayed version of the packet itself sent. If that packet would have been sent, but notreceived due to interference, that would result in a false positive flagged by the IDS. It istherefore important to test how the IDS performs in both lossy and lossless networks.

Runtime and iterations

The simulation will run each setup four times for 30 minutes and the results will mainlyfocus on the total ratio of detected attacks and total true positive ratio of all the simulations.SVELTE however did run analysis on how the true positive rate was affected after 5,10,20 and30 minutes, but this was considered to not matter in the case of the evaluation of this IDS.

Detection and prevention

The IDS can be run both with detection only or with detection and prevention. When runningdetection only, each node only flag that a node is acting maliciously and does not blacklist orsend blacklist reports to neighboring nodes. When running detection and prevention at thesame time, the ids will alert neighboring nodes that a node is acting maliciously and whenenough reports has been filed, the flagged node will be blacklisted and all routes will be reset,since cached routes might have dependencies to the blacklisted node.

Experiment evaluation metrics

• Detection ratioFor each attack, selective forwarding and sinkhole, the detection ratio will be calculatedby matching each performed attack by a malicious node to an alert by any other node.Since a malicious node might have many neighbors, all those neighbors can possiblydetect a malicious node, but an attack is considered as detected if at least one of theneighboring nodes detect the attack.

• True and false positivesTrue and false positives considers when a node flags another node, if that flag was aflag of a real attack or if it falsely flagged a node. A true positive therefore is when areport about a node was a correct report, i.e. a node performed a selective forwardingattack and another node detected that. A false positive would then be if a node wasflagged as a selective forwarding attack because it did not hear the packet it sent beingrelayed, which could be due to interference or the relaying node not having a route tothe destination.

• Payload delivery ratioWhen malicious nodes performs the attacks on the network, the messages will not al-ways be delivered to the destinations, especially when performing the Selective for-warding attack. Therefore, it is interesting to investigate how the payload delivery ratiois affected by the IDS’s prevention module. The payload delivery ratio is calculated byanalyzing how many of the sent messages reaches the intended destination and thatalso successfully sends the same message back to the source.

53

4 Results

4.1 Sinkhole and Selective forwarding detection and prevention results

The following section presents the results of simulating the different network scenarios. Eachscenario was simulated four times each and the numbers in the following tables and graphsreflects the output from all four simulations added together. In each simulation, the maliciousnode /nodes executes both sinkhole and selective forwarding attacks.

When further on referring

• Detection Ratio: How many of the executed attack instances that any one node noticedand reported as that attack.

• True Positive: How many of the reports about a node and attack that was correctlyflagged.

• True Positive Ratio: How many percent of all reports about a node that was a truepositive.

• False Positive: How many of the reports about a node and attack that was incorrectlyflagged, i.e. a non malicious node being falsely flagged for being malicious.

• False Positive Ratio: How many percent of all reports about a node that was a falsepositive.

• Payload delivery ratio: How man percent of all messages sent that was delivered prop-erly and replied with a correct response that was delivered back to the originating nodeproperly.

• Route Flush Commands: When the IDS has prevention enabled, how many of the sentRoute Flush Commands that was sent, i.e. when a node blacklists another node andwants the complete network to reset their route tables.

• True Positive Route Flush Commands: How many route flush commands that weresent about a node that was correct, i.e. about a malicious node that performed attackson the network. The numbers presented in the table is the total of all 4 simulations, toget the mean of each simulation, the number should be divided by 4.

54

4.1. Sinkhole and Selective forwarding detection and prevention results

• True Positive Route Flush Command Ratio: The percentage of the total amount of routeflush commands that was correct.

• False Positive Route Flush Commands: How many route flush commands that weresent about a node that was incorrect, i.e. about a non malicious node. The numberspresented in the table is the total of all 4 simulations, to get the mean of each simulation,the number should be divided by 4.

• False Positive Route Flush Command Ratio: The percentage of the total amount of routeflush commands that was incorrect.

The false positive ratios is not included in the graphs or tables since the information canbe considered redundant because

FalsePositiveRatio = 100%´ TruePositiveRatio

Sinkhole Detection

The first test was to find out how well the IDS detected malicious nodes executing sinkholeattacks with no prevention enabled in the IDS, i.e. only detection.

Lossless

In the scenario of a lossless network model, the sinkhole detection achieved the results givenin 4.1a with a low detection ratio of 26% in the case of 8 network nodes, but higher detectionratio at 93% and 89% in the case of 16 and 32 nodes respectively.

For true detection, results of 100% for 8 nodes was achieved. Worth noting is that a totalof only 12 attacks was able to be performed due to the small network. That is because amalicious node only alters the hop count in RREQ messages and set it to at best 1. When thenetwork is as small as it is, not many nodes have more than 2 hops to the source, and becauseof that, the malicious node cannot appear to be better than at most 1 hop away, which manyother nodes also can have and since not making the malicious node’s route more beneficialthan other nodes.

In the case of 16 and 32 sized networks, the results for true positive ratio were 95% and92% leaving 5% and 8% false positive rate with a mean of 5 and 15 false positives per simula-tion respectively .

The payload delivery is heavily reduced to 4% to 18% due to the malicious node/nodesbeing present and performing its attacks.

Table 4.1: Sinkhole detection without IDS prevention, lossless

Total sinkhole Total sinkhole sinkholeAttacks Attacks Detected Detection Ratio

8 nodes 45 12 26%16 nodes 60 56 93%32 nodes 266 237 89%

Table 4.2: Sinkhole true and false positives, without IDS prevention, lossless

Total sinkhole True False TrueAttacks Alerted Positives Positives Positive Ratio

8 nodes 12 12 0 100%16 nodes 416 396 20 95%32 nodes 798 738 60 92%

55

4.1. Sinkhole and Selective forwarding detection and prevention results

Table 4.3: Payload delivery ratio with IDS prevention, lossless

Total Messages Total Messages Payload DeliverySent Delivered Ratio

8 nodes 476 22 4%16 nodes 505 60 11%32 nodes 541 101 18%

Lossy

In the scenario of a lossy network model, the sinkhole detection achieved the results given in4.1b with a slightly higher, than the lossless case, detection ratio of 27% in the scenario of 8network nodes. For 16 and 32 sized networks the detection rate was higher than the 8 nodecase, with 78% and 66% respectively which is lower than the lossless scenario.

For true detection, results of 100% for 8 nodes was achieved. Worth noting is that a totalof only 12 attacks was able to be performed due to the small network. That is because amalicious node only alters the hop count in RREQ messages and set it to at best 1. When thenetwork is as small as it is, not many nodes have more than 2 hops to the source, and becauseof that, the malicious node cannot appear to be better than at most 1 hop away, which manyother nodes also can have and since not making the malicious node’s route more beneficialthan other nodes.

In the case of 16 and 32 sized networks, the results for true positive ratio were 71% and82% which is worse than the lossless case by 24% and 10% respectively. This also means thatthe false positive ratio went up in the lossy case from 5% to 29% and from 8% to 18%.

The payload delivery ratio was in the lossy case 25%, 11% and 10% for 8, 16 and 32 nodesrespectively compared to the lossless case of 4%, 11% and 18%. In the size 8 network, thepayload delivery ratio was better in the lossy case. The lossy case sent about 595 messages,25% more messages than lossless, and achieved 153 proper messages that was delivered andresponded while in the lossless case, the same number was 22.

Table 4.4: Sinkhole detection without IDS prevention, lossy

Total sinkhole Total sinkhole sinkholeAttacks Attacks Detected Detection Ratio

8 nodes 36 10 27%16 nodes 184 144 78%32 nodes 427 285 66%

Table 4.5: Sinkhole true and false positives, without IDS prevention, lossy

Total sinkhole True False TrueAttacks Alerted Positives Positives Positive Ratio

8 nodes 14 14 0 100%16 nodes 644 460 184 71%32 nodes 558 459 99 82%

56

4.1. Sinkhole and Selective forwarding detection and prevention results

Table 4.6: Payload delivery ratio during a sinkhole attack with IDS prevention, lossy

Total Messages Total Messages Payload DeliverySent Delivered Ratio

8 nodes 595 153 25%16 nodes 504 60 11%32 nodes 485 49 10%

Network size

8 16 32 0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Sinkhole detection, no prevention, lossless

Sinkhole Detection Ratio

Sinkhole True Positive Ratio

Payload Delivery Ratio

(a) Graph of sinkhole detection results without IDS prevention disabled, lossless. Exact numbers can befound in Tables 4.1, 4.2, 4.3.

Network size

8 16 32 0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Sinkhole detection, no prevention, lossy

Sinkhole Detection Ratio

Sinkhole True Positive Ratio

Payload Delivery Ratio

(b) Graph of sinkhole detection results without IDS prevention disabled, lossy. Exact numbers can befound in Tables 4.4, 4.5, 4.6.

Figure 4.1: Graphs with the results of the sinkhole detection

57

4.1. Sinkhole and Selective forwarding detection and prevention results

Selective Forwarding Detection

The second test was to find out how well the IDS detected malicious nodes executing SelectiveForwarding attacks with no prevention enabled in the IDS, i.e. only detection.

Lossless

In the scenario of a lossless network model, the Selective Forwarding detection achieved theresults given in 4.2a with a high detection ratio of 100% in the 16 size case and 99% in the 8and 32 size case.

For true detection, results of 99% for 8 and 32 nodes and 100% for 16 nodes was achieved.This was achieved even though the number of attacks was considerable large.

As with the sinkhole attack, the payload delivery ratio is much alike and that is becauseno actions were taken to mitigate the malicious node performing the attacks on the network.

Table 4.7: Selective Forwarding detection without IDS prevention, lossless

Total Total SelectiveSelective Selective Forwarding

Forwarding Forwarding DetectionAttacks Attacks Detected Ratio

8 nodes 449 446 99%16 nodes 445 445 100%32 nodes 414 412 99%

Table 4.8: Selective Forwarding true and false positives, without IDS prevention, lossless

Total Selective Forwarding True False TrueAttacks Alerted Positives Positives Positive Ratio

8 nodes 933 932 1 99%16 nodes 2140 2140 0 100%32 nodes 980 979 1 99%

Table 4.9: Payload delivery ratio without IDS prevention, lossless

Total Messages Total Messages Payload DeliverySent Delivered Ratio

8 nodes 476 22 4%16 nodes 517 72 13%32 nodes 556 114 20%

Lossy

In the scenario of a lossy network model, the selective forwarding detection achieved theresults given in 4.2b 100% detection ratio in the 8 and 16 nodes case, and 98% detection ratioin the 32 nodes case where on average, only one attack per simulation was missed. That issimilar as in the lossless case.

For true detection ratio, 8 nodes size got 54% with 300 false positives, compared to the99% detection rate and 1 false positive in the lossless case. The 16 nodes size network got72% true detection rate and 444 false positives, compared to 100% true detection rate an 0false positives in the lossless case. The 32 nodes size network achieved 55% true detection

58

4.1. Sinkhole and Selective forwarding detection and prevention results

rate and 347 false positives compared to 99% detection rate and 1 false positive in the losslesscase.

The payload delivery ratio was 20%, 8% and 12% for 8,16 and 32 nodes respectively com-pared to 4%, 13% and 20% in the lossless case.

Table 4.10: Selective Forwarding detection without IDS prevention, lossy

Total Total SelectiveSelective Selective Forwarding

Forwarding Forwarding DetectionAttacks Attacks Detected Ratio

8 nodes 228 228 100%16 nodes 365 365 100%32 nodes 223 219 98%

Table 4.11: Selective Forwarding true and false positives, without IDS prevention, lossy

Total Selective Forwarding True False TrueAttacks Alerted Positives Positives Positive Ratio

8 nodes 661 361 300 54%16 nodes 1614 1170 444 72%32 nodes 788 441 347 55%

Table 4.12: Payload delivery ratio without IDS prevention, lossy

Total Messages Total Messages Payload DeliverySent Delivered Ratio

8 nodes 563 113 20%16 nodes 485 40 8%32 nodes 507 63 12%

59

4.1. Sinkhole and Selective forwarding detection and prevention results

Network size

8 16 32 0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Selective forwarding detection, no prevention, lossless

Selective Detection Ratio

Selective True Positive Rato

Payload Delivery Ratio

(a) Graph of Selective Forwarding detection results with IDS prevention disabled, lossy. Exact numberscan be found in Tables 4.7, 4.8, 4.9.

Network size

8 16 32 0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Selective forwarding detection, no prevention, lossy

Selective Detection Ratio

Selective True Positive Rato

Payload Delivery Ratio

(b) Graph of Selective Forwarding detection results with IDS prevention disabled, lossy. Exact numberscan be found in Tables 4.10, 4.11, 4.12.

Figure 4.2: Graphs with the results of the selective forwarding detection

Sinkhole and Selective Forwarding Detection with prevention

The earlier simulations did not have the prevention module in the IDS enabled leaving theIDS with only detection on. For the last tests, the prevention module was enabled and actedin the way that if a node misbehaved a certain amount of time, it would get blacklisted andthe route tables in the complete network would be reset. The attack however was performedin the same way as the earlier simulations where the prevention module was not enabled, thatis, a malicious node performed a combination of sinkhole and selective forwarding attacks.

Lossless

The results of the simulations with IDS prevention and lossless network model can be foundin figure 4.3a. As can be seen in the figure, in the 8 sized network case, the IDS performs very

60

4.1. Sinkhole and Selective forwarding detection and prevention results

well with 100% detection rate on both sinkhole and selective forwarding attacks, 100% truedetection rates at both attacks, a 100% true flush ratio and a payload delivery ratio of 98%,with a total of over 4800 messages sent, compared to a payload delivery ratio of 4% when notusing prevention.

Already after on average, 1 minute and 9 seconds, the malicious node was identified andblacklisted from the network. All future traffic was therefore unaffected by the maliciousnode’s attempts to attack the network.

When the bigger networks was simulated however, the results decreased somewhat.For 16 sized networks, the sinkhole detection was reduced to 91% and the true detection

ratio to 63%. The Selective forwarding detection however was 100% but with a true detectionratio of only 32% leaving a false positive rate at 68% with 252 false positives. In all simula-tions, all malicious nodes was reported as malicious already after on average just past the 3minute mark. However, 3 other nodes did later on also get marked as malicious nodes andgot blacklisted due to false positives. Since all the malicious nodes was blacklisted early on,the payload delivery ratio was increased to 92% compared to 13% in the case of no preven-tion.

For 32 sized networks, sinkhole detection became 63% with a true positive rate of 98%.Selective forwarding was 100% with a true positive ratio of only 29% and 162 false positives.The high false positive rate resulted in that on average, 2.5 nodes was falsely marked asmalicious and excluded for future communication. One malicious node was also not flaggedas malicious after the whole 30 minutes which lead it to continue to perform its attacks duringthe complete simulations. This affected the payload delivery ratio somewhat to begin 53%,compared to about 18% without prevention.

Table 4.13: Sinkhole detection with IDS prevention, lossless

Total sinkhole Total sinkhole sinkholeAttacks Attacks Detected Detection Ratio

8 nodes 8 8 100%16 nodes 524 480 91%32 nodes 2047 1299 63%

Table 4.14: Sinkhole true and false positives, with IDS prevention, lossless

Total sinkhole True False TrueAttacks Alerted Positives Positives Positive Ratio

8 nodes 8 8 0 100%16 nodes 2896 1852 1044 63%32 nodes 2296 2273 23 98%

Table 4.15: Selective Forwarding detection with IDS prevention, lossless

Total Total SelectiveSelective Selective Forwarding

Forwarding Forwarding DetectionAttacks Attacks Detected Ratio

8 nodes 20 20 100%16 nodes 24 24 100%32 nodes 31 31 100%

61

4.1. Sinkhole and Selective forwarding detection and prevention results

Table 4.16: Selective Forwarding true and false positives, with IDS prevention, lossless

Total Selective Forwarding True False TrueAttacks Alerted Positives Positives Positive Ratio

8 nodes 40 40 0 100%16 nodes 372 120 252 32%32 nodes 230 68 162 29%

Table 4.17: Payload delivery ratio with IDS prevention, lossless

Total Messages Total Messages Payload DeliverySent Delivered Ratio

8 nodes 4856 4794 98%16 nodes 2686 2488 92%32 nodes 832 446 53%

Table 4.18: Route flush commands, lossless

Total True Positive False Positive True Positive TotalRoute Flush Route Flush Route Flush Route Flush FalselyCommands Commands Commands Ratio Flushed

Sent Sent Sent Nodes8 nodes 4 4 0 100% 016 nodes 28 16 12 57% 1232 nodes 28 20 8 71% 8

Lossy

As for the lossy case, the IDS did not perform as well as in the lossless one. While the SelectiveForwarding detection stayed at 100%, the true positive ratio went down in all network sizes.The 8 node size network went from 100%, 32% and 29% true positive rate to 19%, 18% and16% for 8, 16 and 32 sized network respectively. The sinkhole detection went from 100%,91% and 63% to 26%, 74% and 59% for 8, 16 and 32 sized networks respectively and for truedetection from 100%, 63% and 98% to 86%, 61% and 88% for 8, 16 and 32 respectively whichis all decreasing results in the lossy case compare to the lossless one.

Thanks to the high false positive ratio on both the sinkhole and selective forwarding de-tection, non-malicious nodes was blacklisted which might also have affected the payload de-livery ratio, which was decreased from 98%, 92% and 29% in the lossless case to 12%, 23% and15% in the lossy case for 8,16 and 32 node networks. This is compared to payload deliveryratio without prevention, 20%, 8% and 12% not that big of an improvement.

Table 4.19: Sinkhole detection with IDS prevention, lossless

Total sinkhole Total sinkhole sinkholeAttacks Attacks Detected Detection Ratio

8 nodes 83 22 26%16 nodes 383 284 74%32 nodes 707 421 59%

62

4.1. Sinkhole and Selective forwarding detection and prevention results

Table 4.20: Sinkhole true and false positives, with IDS prevention, lossy

Total sinkhole True False TrueAttacks Alerted Positives Positives Positive Ratio

8 nodes 30 26 4 86%16 nodes 1108 680 428 61%32 nodes 683 605 78 88%

Table 4.21: Selective Forwarding detection with IDS prevention, lossy

Total Total SelectiveSelective Selective Forwarding

Forwarding Forwarding DetectionAttacks Attacks Detected Ratio

8 nodes 18 18 100%16 nodes 28 28 100%32 nodes 24 24 100%

Table 4.22: Selective Forwarding true and false positives, with IDS prevention, lossy

Total Selective Forwarding True False TrueAttacks Alerted Positives Positives Positive Ratio

8 nodes 145 28 117 19%16 nodes 484 88 396 18%32 nodes 304 51 253 16%

Table 4.23: Payload delivery ratio with IDS prevention, lossy

Total Messages Total Messages Payload DeliverySent Delivered Ratio

8 nodes 505 63 12%16 nodes 619 144 23%32 nodes 502 77 15%

Table 4.24: Route flush commands, lossy

Total True Positive False Positive True Positive TotalRoute Flush Route Flush Route Flush Route Flush Falsely

Commands Sent Commands Sent Commands Sent Ratio Flushed Nodes8 nodes 22 8 14 36% 1116 nodes 32 12 20 37% 1632 nodes 26 19 7 73% 5

63

4.1. Sinkhole and Selective forwarding detection and prevention results

Network size

8 16 32 0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Sinkhole and Selective detection, with IDS prevention, lossless

Sinkhole Detection Ratio

Sinkhole True Positive Ratio

Selective Detection Ratio

Selective True Positive Rato

Payload Delivery Ratio

True Flush Ratio

(a) Graph of Selective Forwarding and sinkhole detection results with IDS prevention, lossless. Exactnumbers can be found in Tables 4.13, 4.14, 4.15, 4.16, 4.17, 4.18.

Network size

8 16 32 0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Sinkhole and Selective detection, with IDS prevention, lossy

Sinkhole Detection Ratio

Sinkhole True Positive Ratio

Selective Detection Ratio

Selective True Positive Rato

Payload Delivery Ratio

True Flush Ratio

(b) Graph of Selective Forwarding and sinkhole detection results with IDS prevention, lossy. Exactnumbers can be found in Tables 4.19, 4.20, 4.21, 4.22, 4.23, 4.24.

Figure 4.3: Graphs with the results of the sinkhole and selective forwarding detection detec-tion when prevention enabled

64

4.2. Sybil detection results

4.2 Sybil detection results

The sybil detection has varied success in different environments, the difference made by thedifferent geographies is showcased in impersonator false negative and false positive in fake-ID.

Impersonator: false positive

Simulating 15 nodes for over 38000 reports, for instance as in figure 4.4, in different environ-ments show the following deviations:

• 5.8% of messages deviate 2 or more standard deviations

• 5% of messages deviate more than 2 standard deviations

• 1% of messages deviate 3 or more standard deviations

• 0.6% of messages deviate more than 3 standard deviations.

• 0.15% of messages deviate 4 or more standard deviations.

From the same data using 2 standard deviations as the cutoff, the amount of messages whichare detected and reported by at least one node is lower than 10%, figure 4.5. This means 90%of messages are cleared by all reporters. Using a threshold of 50% of reporters identifying anattack leads to a 2.9% false positive rate and more than 50% leads to a 1.9% false positive ratein this general case.

Impersonator: false negative

In network 4.6 node 7 presents itself as node 4, with deviations as in 4.7. Comparing thereceived RSSI from node 7, the impersonator, to the RSSIs of the real node this scenario showsthat of the impersonators messages, for all evaluating nodes:

• 22% are within 2 standard deviations of the norm for node 4.

• 33% are within 3 standard deviations of the norm for node 4.

• 34% are within 4 standard deviations of the norm for node 4.

Analyzing the data in figure 4.8, the worst found scenario, shows that 7% of the messagesfrom the sybil node is not considered suspicious by any node and that 25% of messages

Deviation of 15 connected nodes

-4 -3 -2 - 0 2 3 4

delta

0

1000

2000

3000

4000

# o

ccure

nces

Figure 4.4: Distribution of 38000 deltas from 15 different nodes reporting plotted against theirstandard deviations.

65

4.2. Sybil detection results

% of nodes incorrectly accusing each message

0 10 20 30 40 50 60 70 80 90 100

percentage

0

20

40

60

80

100

% o

ccure

nces

Figure 4.5: The amount of reports/message suspecting sybil attack.

Figure 4.6: Network in which node 7 spoofs the address of node 4.

Data distribution after attack

-4 -3 -2 - 0 2 3 4

delta

0

50

100

150

200

# o

ccu

ren

ce

s

Figure 4.7: The deviations of incoming reports for all nodes neighboring 4 and 7.

% of nodes correctly accusing each message

0 10 20 30 40 50 60 70 80 90 100

percentage of nodes reporting

0

10

20

30

% o

ccure

nces

Figure 4.8: The % of reports correctly identifying each message as from an impersonator.

66

4.2. Sybil detection results

% of nodes correctly accusing each message

0 10 20 30 40 50 60 70 80 90 100

percentage of nodes reporting

0

50

100

% o

ccure

nces

Figure 4.9: The % of reports correctly identifying each message as from an impersonator.

are deemed suspicious by less than half of the reporting nodes, meaning if a 50% reportrate/message was used to determine the legitimacy the false positive rate would be 25%

Analyzing the data in figure 4.9, another scenario, shows that less than 4% messages passundetected by any node. 4.7% of all messages are reported by less than half of the nodes.Giving a 4.7% false negative rate, or 95.3% true positive rate when using 50% reports as limitfor identifying messages as sybil. These results show that the geographical position of theattacking node has a large impact on the effectiveness of the system.

(a) (b)

(c) (d)

Figure 4.10: Sybil environment for comparing proximity of node 4 and 6.

67

4.2. Sybil detection results

Fake-ID: false positive

Using two standard deviations as limit for proximity of two nodes show differing resultsbetween environments, four different environments where everything is the same apart fromnode 6 being moved around is shown in figure 4.10. Reports for each of the environmentson node 6 being suspected to be the same as node 4 is presented in 4.11. Results for eachsituation:

(a) 0.7% are reported by 50% or more, 0.1% are reported by more than 50%

(b) 11% are reported by 50% or more, 3.5% are reported by more than 50%

(c) 38% are reported by 50% or more, 23% are reported by more than 50%

(d) 93.5% are reported by 50% or more, 88% are reported by more than 50%

% of nodes incorrectly accusing each message

0 10 20 30 40 50 60 70 80 90 100

percentage

0

20

40

60

80

% o

ccu

ren

ce

s

(a)

% of nodes incorrectly accusing each message

0 10 20 30 40 50 60 70 80 90 100

percentage

0

10

20

30

40

50

% o

ccu

ren

ce

s

(b)

% of nodes incorrectly accusing each message

0 10 20 30 40 50 60 70 80 90 100

percentage

0

10

20

30

% o

ccure

nces

(c)

% of nodes incorrectly accusing each message

0 10 20 30 40 50 60 70 80 90 100

percentage

0

10

20

30

40

50

% o

ccure

nces

(d)

Figure 4.11: Sybil reports proximity between 4 and 6

68

4.2. Sybil detection results

% of nodes correctly accusing each message

0 10 20 30 40 50 60 70 80 90 100

percentage

10

20

30

40

50

60

% o

ccu

ren

ce

s

Figure 4.12: Sybil reports proximity between 4 and 6

Fake-ID: false negative

Using two standard deviations as limit again, the data from figure 4.12, shows that an attackercan be correctly identified to have made up an ID by 50% or more of nodes 88% of the time,leading to a false negative rate of 12%, while requiring strict majority the false negative rateis 23%.

Overhead

In this implementation each node that hears a non-IDS-message will send out a report mes-sage which means each message will create at most N messages where N is the amount ofnodes within transmission range (neighbors).

69

5 Discussion

5.1 Results

Achieving security in the IoT-world is still far off. Security concerns are currently gainingmore attention as the new versions of the popular protocols add security in the form of usingsecure key exchanges, adding ease of use encryption tools. The speed of which these devicesreach a secure state might be increased by people becoming increasingly aware of the dangersthat cheap connected come with as hacks gaining much media attention. At the same timesecurity measures are held back by cost as a secure device will cost a lot more to producethan an insecure one as the hardware needs to be better and the time and cost to reach marketincreases with the workload on software engineers.

Analysis of Sinkhole & Selective Forwarding detection and prevention

When looking at the results presented in the results section, as expected, the lossy cases didnot perform as well as the lossless cases. This was because the IDS relies on bi-directionallinks between its neighbors for verification. When in the lossy case, a message is expected tobe heard relayed but interference in the network model, i.e. loss of information, makes thatmessage not getting received on the verifying node, it will generate false positives. So eventhough the detection ratio of the attacks was relatively high, many times 100% or around that,the solution the IDS is built upon will be plagued by false positives when used in realisticnetwork environments since it is meant to be placed in the IoT with constrained hardware.

The following subsections will handle and analyze the results for detection of each attackand the prevention mechanism in the IDS. The evaluation of SVELTE achieved almost 100%detection rate for both sinkhole attacks and selective forwarding attacks and almost 100%true detection for sinkhole attacks when simulated with the lossless network model. Whencomparing the IDS implemented in this thesis with SVELTE some things are worth noting.

SVELTE is a centralized solution, with unlimited hardware resources as goes for analyzingthe routing information while the IDS in this thesis is a distributed one where all analysis isdone on each node. The IDS in this thesis relies on each node analyzing all the heard messagesthat it can, even if the message was not sent to or from itself. However, since the IDS in thisthesis is distributed on all nodes, that means that the memory usage and computing power isalso distributed on all nodes and because of the limited hardware, the IDS can not be as large

70

5.1. Results

or complex as it can in SVELTEs centralized, unlimited hardware resources, solution. Thedifferences between the routing protocols can not be disregarded either. The RPL protocolanalyzed in SVELTE is a more fully featured protocol compared to the lightweight AODVthat is present in the Rime stack in Contiki. This also makes SVELTE less prone to falsepositives due to built in error handling and route healing mechanisms in the protocol.

Analysis of the Sinkhole detection

Overall the sinkhole detection perform well except with the small sized network. The detec-tion ratio is around 90% for the lossless case if not counting the small sized network, whileit decreases when simulating with the lossy model. The reason that it decreases for the lossymodel is because even though a malicious node performs an attack, the message it sendscould sometimes not have been received thus leaving an attack performed but not heard anddetected by any node. Also, since the IDS is distributed and relies on verifying messagesheard by neighbors as well, when using the lossy model, those messages by the neighborsmight sometime not have been heard so no help by the neighborhood would have added tothe detection. Worth noting is that the true detection ratio for the sinkhole attacks is still over90%, so the attack attempt messages that the nodes actually receives can be identified andclassified considerably well.

As stated, for the small 8 sized network, the sinkhole detection did not perform that well.One reason for that was the way the network nodes was placed. Many of the nodes werealready direct neighbors to the source node or just one hop away from it making any changesto the hop count not being noticed. However, all attacks that was reported was correct bothin the lossless and lossy case.

For the 16 and 32 sized networks, the detection was better and that is most likely alsobecause of the placement of the nodes and the malicious nodes. The malicious nodes wasplaced more than 2 hops from the source which made the surrounding nodes notice that amalicious node altered its hops more effectively.

A comparison of SVELTE and the one IDS in this thesis, found in table 5.1, shows thatthe IDS’s performs similar in the lossless cases but not the lossy ones. That might be ofreasons described above when malicious nodes perform its attacks but no node hears thatmessage due to the lossy environment. A more in depth discussion about false positives willbe handled later on in this chapter.

Table 5.1: Sinkhole true detection comparison with SVELTE, lossless after 30 minutes of sim-ulating

Lossless, Thesis IDS Lossless, SVELTE Lossy, Thesis IDS Lossy, SVELTETrue Positive ratio True positive ratio True Positive ratio True positive ratio

8 nodes 100% ~100% 27% ~90%16 nodes 95% ~100% 78% ~90%32 nodes 92% ~100% 66% ~90%

Analysis of the Selective Forwarding detection

For selective forwarding, the IDS performs very well in terms of detection ratio. In all cases,even the lossy cases, it has a detection ratio at 100%, or close to that. The true detection ratiois also good as goes for the lossless case with results of 99%-100%, with only one false positivereport in the cases of 99% true detection ratio. However, when using the lossy network model,the false positive rate ranges from 28% to 46% which would result in nodes being falselyblacklisted if using prevention. The reason to the high false positive ratio in the lossy networkmodel is mainly due to how the IDS detects a selective forwarding attack, that is by listeningto verify that nodes forward the messages as expected, and if a node is expected to forward a

71

5.1. Results

message and that message gets lost due to interference in the lossy network model, that nodedid not act maliciously but was marked as such anyway.

Other reasons that false positives can occur is if a source node think it has a route to adestination and somewhere on the path to that destination, another node that is supposedto have a route setup can not reach its next neighbor. In that case, that node starts a routediscovery process and if it that route discovery process does not yield a new route in time,the node will not send that messages further and thus the surrounding nodes that expectedthe message to be relayed will report that node as malicious for not forwarding the message.In the lossy case, the route setup can therefore also be disrupted by the lossy environmentand since the lightweight routing protocol used in Rime is not that fully featured and lacksmany route healing mechanisms, problems with non-existing routes raises the false positivesas well.

Since the IDS is supposed to be placed in the IoT and the real world, where the circum-stances are not ideal as in the lossless case, the high false positive rate would need to beconsidered and a more advanced mechanism for blacklisting nodes would be necessary tofilter out the false positives.

When comparing the IDS in this thesis to SVELTE, they both perform similar in terms ofdetection rate, almost 100% for both, and in terms of true positive ratio in the lossless case,where SVELTE however performs worse when network size grows.The interesting metrichowever lies in the lossy evaluation. SVELTE performs better in terms of true detection ra-tio where SVELTE reaches ~85% and the IDS in this thesis reaches a maximum of 72% truedetection ratio in one case but only about 55% in the other two cases.

Table 5.2: Selective Forwarding true detection comparison with SVELTE, lossless after 30minutes of simulating

Lossless, Thesis IDS Lossless, SVELTE Lossy, Thesis IDS Lossy, SVELTETrue Positive ratio True positive ratio True Positive ratio True positive ratio

8 nodes 99% ~100% 54% ~85%16 nodes 100% ~95% 72% ~80%32 nodes 99% ~85% 55% ~75%

Analysis of the IDS with prevention enabled

As shown in the results chapter, the IDS with its prevention module enabled showed verygood results in the lossless case and 8 sized network with 100% detection and true detectionratio for both sinkhole, selective forwarding and the flush ratio. The payload delivery ratiowas also affected by this because the early discovery of the malicious node which came to be98%. For the other cases, the payload delivery was affected in a positive way with increasesfrom about 10% to 93% and 53% for 16 and 32 sized networks. The reason the 32 sized net-work did not reach as high payload delivery ratio as the smaller networks was because in allsimulations, every malicious node did not get detected and blacklisted and therefore affect-ing the network traffic. Also, the lightweight routing protocol did not handle larger networksthat good since the route setup time increases and the data messages could many times time-out before a proper route was found. That also contributed to the high false positive ratiosof almost 70% in both the 16 and 32 networks since a failed route setup would result in afalse positive being generated because nodes would not continue to forward messages dueto them not knowing which the next hop was.

The reason for needing the route flush was that route inconsistencies would occur if onlyeach node by itself were to blacklist its reported malicious nodes. To make sure that the net-work was in sync with what malicious nodes that was found, all routes in the route cacheshad to be reset. This opens up for attackers to exploit this functionality to flush routes con-tinuously so no network traffic could be sent in the network. This was a consideration that

72

5.1. Results

was made with the distributed mechanism so the neighborhood could help each other tofind malicious nodes. The risk of a malicious attacker exploiting that feature however wasconsidered, and will be discussed further later on.

Further for the issued route flush commands, needed to clear the route caches of all net-work nodes and properly blacklist a suspected malicious node, in the lossless case, the IDSalso struggles with false positives ratios of 43% and 29% resulting in 2-3 nodes being wrong-fully blacklisted each simulation. Depending on the application of the network nodes, thiscould be unacceptable

However, the nodes would anyway be able to alert the network administrator that somemalicious activity is going on in the network and that something has to be done about it.

In conclusion. The IDS with prevention enabled do raise the payload delivery ratio forlossless networks, but with larger and more complex networks, false positives will be presentand legit nodes will be excluded falsely. Lossy networks does however not detect all attacksand many false positives are present with a payload delivery ratio getting only marginallybetter. If the IDS ,with prevention enabled, were to be run in a lossless environment, it couldbe considered to perform somewhat okay if it would be allowed to falsely blacklist one or afew nodes to raise the payload delivery ratio. In the lossy case however, since the payloaddelivery ratio did not raise even with the prevention module enabled, and the amount of falsepositives, it should be considered not usable

False positives

The number of false positives that is accepted as IDS is a consideration that has to be donewhen deciding to use one. A 100% detection and true detection rate might be very hardto achieve. Depending on the affects the false positives have on the network, some falsepositives could maybe be accepted, if the application of the network allows for it. For othernetworks where every node plays a vital part of the network, such false positives wouldnot be acceptable. Therefore, careful considerations needs to be payed attention to wheninstalling an IDS in a network.

Weaknesses of the IDS detecting Selective Forwarding and Sinkhole attacks

The IDS was built to detect routing attacks to raise the payload delivery ratio. With theprevention module enabled, each node reports to its neighborhood about nodes it suspectsbeing malicious. This feature of voting could in turn be abused by a malicious node by falselyaccuse legit nodes of being malicious. This is a flaw that exists because of the distributedsolution of the IDS where the blacklisting is built on the neighborhood cooperating to detectmalicious nodes. Therefore there are ways to attack the network by exploiting the IDS. Thiscan be done by sending many false reports which will lead to blacklisting of that node. Amalicious node could also send route flush commands to all the time flush the cached routeswhich in itself is a new way to perform a denial of service attack on the network. The securityof a solution should not lie in the safekeeping of a that solution or algorithm, which makesthe IDS opening up more attack surfaces while only closing a few with high risks of falselyblacklist legit nodes, resulting in the IDS performing a denial of service on itself which isas severe as the routing attack itself. More security mechanisms would therefore have to beimplemented to make sure that the detection rate gets higher, and false positive rate getslower.

Also, since there does not exist a decay function for the blacklist reports, sooner or laterwhen many nodes have been falsely reported, those nodes will be blacklisted when the net-work has been running for long periods of time resulting in all nodes being blacklisted.

73

5.1. Results

Possible improvements of the IDS

There are several ways that the IDS can be improved such that the false positive ratio goesdown.

For starters, a decay function on the number of reports a node has gotten could with timereduce the number of nodes being blacklisted with time.

Depending on how long time it can take for a malicious node to be blacklisted, the thresh-old for blacklist reports before a blacklist is issues could be raised.

A support vector machine could be implemented with machine learning to learn the statis-tics for how many messages on average a node does not forward, or the number of inconsis-tencies of RREQ hops when setting up a route, and if a node acts anomalously, it will onlythen be reported and blacklisted.

A network setup with cluster heads could be used where one node in the neighborhoodis voted to be a cluster head, and all network traffic goes through that one node to the sourcesuch that those cluster head nodes can be the verifying nodes which are the only ones allowedto send out blacklist reports to its own cluster nodes.

A solution with cluster heads would strengthen the security a bit more. The cluster heads,voted by the neighborhood, would then be considered a trusted node, and all traffic wouldgo through that node. That node would then also be responsible for all the detection to itschildren so that they behave accordingly. However, a malicious attacker could still spoof theID of that cluster head and act as it. The sybil detection should however be able to detect this.

Attacking the IDS

As mentioned earlier, there are ways to attack the IDS as an attacker. One of the most severeis if an attacker broadcasts blacklist reports of legit nodes which will make the legit nodesbeing blacklisted and excluded from the network. This can have serious consequences if thewrongfully blacklisted nodes serves a crucial service to the network and introduces risk to amore powerful attack being performed than the ones the IDS are protecting from.

One way to mitigate this would be if every node could authenticate itself using for exam-ple encryption. However, lack of end-to-end encryption or authentication is a delimitationthat was chosen for this thesis because of the complexity the managing of the encryption keysadds.

Another way to mitigate the process of falsely blacklisting nodes is to disable the ability toreport to other nodes in the neighborhood about suspected malicious nodes, and only containa private blacklist of nodes acting maliciously. With that solution however, all maliciousnodes might not be detected, and the time to detect all malicious nodes will take much longer.Another result of a individual blacklist would be that other nodes might not know when anode has blacklisted another. Then the blacklisting node might itself be considered maliciousfor not forwarding packets to, or build routes that the blacklisted node tries to setup whichcan lead to falsely blacklisting nodes.

Analysis of Sybil Detection

The results clearly show that canceling the transmitter power and analyzing the quota be-tween two nodes’ RSSI yields results that can be used to determine the relative geographicalposition of nodes without any actual knowledge of the geographical position of nodes. Fur-thermore the results show that an RSSI-method can be used to identify a node pretending tobe a node that it is not as well as identifying a node that creates multiple identities.

Weaknesses of Sybil Detection using RSSI

The amount of false positives approaches 100% as nodes approach the same geographicalposition. This behavior is expected and reaching a 100% false positive rate in a scenario

74

5.1. Results

Figure 5.1: The sybil node, S, can successfully impersonate node 3 without 1 or 2 detecting it.

where two nodes are placed on the exact same position rather shows that the IDS is workingas intended, as two nodes on the same position is geographically the same as one node withtwo identities broadcasting. The smaller the distance required to differ two nodes from eachother the more freedom the user has in placing their devices. As an environment with fewinterferences creates a smaller standard deviation, these environments can hold nodes closerto each other than noise heavy areas.

As a message always will arrive before the report it will cause a delay if the messageis supposed to be authenticated as real before retransmitting it if it is a multihop messagesupposed to be forwarded, or acting on it when it reaches the intended receiver. Dependingon how critical low delivery time of a message is a delay system could be implemented tomanage stolen IDs. In this delay system messages are delayed for a time or until a numberof reports is satisfied and the message is successfully authenticated as within the approvedamount of standard deviations before forwarding or acting upon it.

In an environment with a lot of local interference the RSSI might be skewed for one nodebut not the other which can cause the standard deviation to be large after training and assuch the RSSI-room in which a sybil node can impersonate other nodes without detection isincreased and the risk of false positives on the proximity based detection is increased. Thereare multiple positions a node can be placed at to yield the same RSSI-quotas for two or morenodes. This area is smaller for low standard deviations than large standard deviations Figure5.1 shows the simplest case of this problem. A situation like this would allow one node tohave its own identity as well as stealing the identity of node 3, behaving maliciously andsuccessfully blacklisting a benign node.

The overhead is quite large for the sybil detection. An alternative implementation couldbe to allow nodes to request reports for a message at random intervals for evaluation. Whenreports fall outside of the allowed spectrum the interval could be reduced. In the scenariowhere one node sends a request for reports on one or a few messages and concludes thata specific node N in the network is operating in a suspicious way, it could send out an alertmessage that reports should always be forwarded about transmissions from node N, meaningan impersonator is suspected. It would be natural to use a cluster head for these decisions,however designating one node to request reports in each neighborhood would induce a singlepoint of failure.

Indirect sybil Attacks are not detected by this IDS. Being able to detect indirect attacks isconsidered another research problem and is not considered.

Attacking the Sybil Detection

The current implementation lacks protection against an attack targeted at it. A sybil attackcan be launched to override voting systems and a voting system is what is used to determineif an attack is present or not. Imagining the scenario where a malicious node knows whichnodes to expect sending a report about its message, the sybil node could also be spoofingreports with an RSSI that would not yield a detection for the system for each neighbor node.

75

5.2. Method

The nodes receiving the reports should then receive two reports about the same message andthus realizing an attack might be underway. This has no effect if the legit node is destroyed orin any other way is disrupted from successfully transmitting reports. As such if the attackermanages to disrupt a majority of nodes in a neighborhood it can get away with spoofing re-ports that clear the node. If all neighboring nodes are disrupted, no reports can be transmittedand the system is circumvented.

An attacker can spoof reports and transmit them as it pleases, and as long as it creates thereports with a fake ID and sends to data messages it will not be detected as reports are notsent about reports. This type of attack is not possible if there is a white list which requires anynew nodes to have multiple of its messages verified by the neighborhood before they listento the contents of any message from the node. Remember that the IDS starts with a trainingperiod where no node is malicious. During this time all nodes that transmit in the networkshould be placed on the white list.

The sybil detection only works when the network is static, i.e. no movement of nodes. Anattacker could spoof as many ID’s or addresses that it wants if it was able to move to newpositions for each new message. This is also a consideration that needs to be addressed sincein the real world, a static network can not be guaranteed, at least not for an attacking node.

5.2 Method

Implementation of the IDS

When starting to implement the IDS in this thesis, a distributed, host based solution waswanted to be tested on a AODV routing protocol. The studied protocol stacks did not haveopen source implementations of their specifications, which lead to the decision to try imple-ment the system in an available, open source environment. The environment also needed tofeature a simulation tool so the system did not have to be tested on real hardware, due tocost and time constraints. This resulted in only a few environments that featured a simulatorand a network stack with a working AODV implementation. Contiki was one of those, andat first glance it looked good since it was easy to setup simulation tests and it has supportfor a lightweight AODV implementation. The AODV implementation however was laterfound to not be fully featured which resulted in the results of detecting and preventing of thelightweight AODV implementation can not be directly applied on a fully featured AODV im-plementation. The results are thus only applicable on the lightweight AODV implementationpresent in Contiki.

Sinkhole & Selective Forwarding detection

The research performed about IDS’s in the theory section gave some inspiration on how toimplement a host based, distributed IDS. Since the knowledge of how much resources thatwas available, it was wanted to keep the IDS as slim as possible. The memory footprint,and the time to analyze a packet was aimed to be as small as possible. This was achievedby only saving one message of each type to analyze. The aim was also to make the IDSflexible and easy to enable or disable. Therefore, the IDS was built as a separate module,high up in the call chain in the mesh module which through callbacks of the underlayingRime primitives forwarded information to the IDS. In hindsight, it could have been easierif the IDS was hooked on right after the incoming packets would have arrived and passedinto the Rime module. This is because each communication primitive constructs parts of amessage and then passes on the responsibility to fill in the rest to the underlaying primitives.Therefore, callbacks to the IDS needs to be added to all primitives so the IDS knows whatdata is being sent. If instead, the IDS would have been in the bottom of the architecture, itwould be the last module to look at an outgoing packet, and the first to look at an incoming.The IDS would then have to know the structure of each type of packet to be able to parse it

76

5.2. Method

and analyze the content, but that would be more efficient than the need for callbacks to theIDS for each primitive which also modifies the primitives in a way that it has to be run withthe IDS.

The comparison with SVELTE is done mostly because it is implemented in the same op-erating system, and that it detected the attacks that was studied in the first part of the report.The IDS’s them self are not really alike at all, aside from them being implemented in Contiki,simulated in Cooja and detecting sinkhole and selective forwarding attacks. Further analysisand comparisons could have been done to other solutions and reports instead, but it felt asa good method to compare with SVELTE because of the similarities surrounding the evalua-tion. By comparing with SVELTE as well, the simulation setups was already decided whichsaved a lot of time. However, the simulations could have been simulated for longer times,since the IDS in this thesis will generate false positives with time, resulting in false blacklist-ing of legit nodes. The IDS in this thesis might therefore perform better than it really doeswhen deployed and run for longer times. The IDS, as is, should therefore not be deployedin a real environment unless some of the provided improvements have been considered tobe implemented. The results should also therefore more be seen as a proof that detection ofattackers is possible, but might not be applicable as is in a real system.

Sybil Detection

As all calculations are done on integer numbers, errors in rounding will occur and minimizingthe error might be energy inefficient. The errors have been controlled but it is difficult to ruleout that it might affect the results of the practical study.

The environment Cooja, in which all simulations took place, is not the same as a realenvironment using actual hardware. The signal strength which is a large part of the sybildetection might not vary in the same intervals, and the differences in an attackers signalstrength might not be detectable in a real situation, or values for false positive rates may beoff.

The next step in developing a detection of sybil attacks would be deploying it in a sensornetwork with real radio signals and determining the effects of the signal in an environmentwith interference but also determining how the data points differ from in the simulation.To properly determine the constant multiplier for the standard deviation tests in differentenvironments on real hardware should be carried out, as it may differ depending on environ-mental factors.

Source criticism

The sources used when performing the research in this thesis was mainly ones available on-line in digital libraries available from Linköping Universality’s online resources. This resultedin most of the sources used being scientific reports with only some being other content liketalks from tech conventions. Much of the research was also concluded by double checkingthe available specifications to get a better picture of how the systems were put together.

77

5.3. The work in a wider context

5.3 The work in a wider context

The information presented in this thesis presents weaknesses that developers should beaware of when designing their products to achieve a high standard of security. It also pro-vides people with malicious intent easily accessible information directly related to hackingthe discussed protocols as well as any device using RIME as its routing protocol. Publishingways to attack different protocols can be viewed as morally wrong but another way of look-ing at it is that security through obscurity would lead to security holes being ignored, creatingticking time bombs that explode when someone with malicious intent finds them. Publishingflaws forces developing parties to upgrade to safer versions and putting the money into it asexecutives chances to deny knowledge about the security flaws diminish. The informationposted in this thesis can be found from other sources apart from here, and as such most of thepresented information simply reduces effort required to hack the system.

78

6 Conclusion

Security in the IoT is considered to be on the rise but is currently far from perfect. It hasbeen shown that all the investigated protocols lack security to accurately detect or mitigateat least a few of the considered attacks. Fortunately later protocols have fewer defects thantheir predecessors. There is a high rate of papers being published about adding the securityto the protocols that they lack, giving developers the ability to add them into their systems.These attacks are not protocol specific and other types of IoT systems may often be able togeneralize the attacks and mitigations proposed for other protocols to apply to their systemwith little effort. ZigBees routing protocol, AODV, has a close resemblance to RIME whichhas been shown to be vulnerable to a multitude of attacks. The solutions showcased can bemodified to fit DSR, the routing protocol in Z-wave. Any IoT system relying on multihoppropagation faces the problems studied and the solution proposed are specific implemen-tations of general concepts which can provide inspiration for solving routing problems onother platforms that cannot implement a full strength anti virus or use individual keys foreach device. The implemented solutions in theory as well as practice has weaknesses whichmust be addressed with further research before becoming feasible in practice.

Mainly the problem of indirect sybil attacks must be solved and the verification that for-warded messages gets sent to actual nodes, i.e. with a whitelist of included nodes in thenetwork, combined with acknowledgements from the receiving node that it received the mes-sage. Otherwise, a malicious node would look like it behaves legit by forwarding messagesto nonexistent nodes. It has been shown that a sybil and sinkhole detection can and must beapplied together to achieve protection from sinkhole attacks if mitigation through a blacklistis to be successfully used.

The solution to detect sinkhole/selective forwarding attacks, evaluated in this thesis alsosuffers from high false positive ratio when applied to a lossy physical medium that mimicsthe real world scenario better than the ideal, lossless, medium. In the sybil detection reportsbecome fewer in a lossy scenario lowering the resolution of detection mechanisms. Therefore,considerations need to be taken for each scenario that the solution would be implemented in,and how the false positives would affect the operation of that network.

For environments where the devices are supposed to perform their function untouchedfor long periods of time, up to years, the energy consumption of the proposed solutions mustbe researched and this approach might be deemed too energy demanding for that scenario.

79

Bibliography

[1] P.C. Van Oorschot A.J. Menezes and S.a. Vanstone. “Handbook of Applied Cryptogra-phy”. In: Electrical Engineering 106 (1997), p. 780. ISSN: 1551305X. DOI: 10.1.1.99.2838. arXiv: arXiv:1011.1669v3.

[2] S. Ali. “Comparative Performance Analysis of AODV and DSR Routing Protocols un-der Wormhole Attack in Mobile Ad Hoc Network on Different Node ’ s Speeds”. In:(2016), pp. 641–644.

[3] E. Barker. “Recommendation for Key Management – Part 1: General”. In: NIST SpecialPublication 800-57 (2016), pp. 1–142. DOI: 10.6028/NIST.SP.800-57pt3r1.

[4] Bluetooth Special Interest Group. “BLUETOOTH SPECIFICATION Version 5.0 Vol 0: &Compliance Requirements”. In: December (2016).

[5] D. Wagner C. Karloff. “Secure routing in wireless sensor networks: attacks and coun-termeasures”. In: Ad Hoc Networks 1.2-3 (2003), pp. 293–315. ISSN: 15708705. DOI: 10.1016/S1570-8705(03)00008-8. URL: http://linkinghub.elsevier.com/retrieve/pii/S1570870503000088.

[6] E. Belding-Royer C. Perkins and S. Das. Ad hoc On-Demand Distance Vector (AODV)Routing. RFC 3561. July 2003. DOI: 10 . 17487 / rfc3561. URL: https : / / rfc -editor.org/rfc/rfc3561.txt.

[7] Contiki. Contiki. 2017. URL: https://github.com/contiki-os/contiki/ (vis-ited on 08/02/2017).

[8] Contiki. Radio duty cycling. URL: https://github.com/contiki-os/contiki/wiki/Radio-duty-cycling (visited on 08/02/2017).

[9] A. Dunkels. “An Adaptive Communication Architecture for Wireless Sensor Net-works”. In: (2007), pp. 335–350.

[10] A. Dunkels. “The ContikiMAC Radio Duty Cycling Protocol”. In: (2011).

[11] A. Shamir E. Ronen C. O’Flynn and A. Weingarten. IoT Goes Nuclear: Creating a Zig-Bee Chain Reaction. Cryptology ePrint Archive, Report 2016/1047. http://eprint.iacr.org/2016/1047. 2016.

[12] H. Ehsan and F.A. Khan. “Malicious AODV Implementation and Analysis of RoutingAttacks in MANETs”. In: (2012), pp. 1181–1187. DOI: 10.1109/TrustCom.2012.199.

80

Bibliography

[13] Ericsson. “More Than 50 Billion Connected Devices”. In: White Paper February (2011),pp. 1–12. DOI: 28423-3149Uen.

[14] X. Cao et.al. “Ghost-in-ZigBee: Energy Depletion Attack on ZigBee-Based Wireless Net-works”. In: IEEE Internet of Things Journal 3.5 (2016), pp. 816–829.

[15] D. Evans. “The Internet of Things - How the Next Evolution of the Internet is Chang-ing Everything”. In: CISCO white paper April (2011), pp. 1–11. ISSN: 09598138. DOI:10.1109/IEEESTD.2007.373646. arXiv: arXiv:1011.1669v3. URL: http://scholar.google.com/scholar?hl=en%7B%5C&%7DbtnG=Search%7B%5C&%7Dq=intitle:The+Internet+of+Things+-+How+the+Next+Evolution+of+the+Internet+is+Changing+Everything%7B%5C#%7D0.

[16] B. Fouladi and S. Ghanoun. Black Hat USA 2013 - Honey, I’m home!! - Hacking Z-Wave Home Automation Systems. Youtube. Dec. 3, 2013. URL: https://youtu.be/tpth0KHYbD0.

[17] B. Fouladi and S. Ghanoun. “Security Evaluation of the Z-Wave Wireless Protocol”. In:Black hat (2013), p. 6.

[18] J. Noh G. Kwon J. Kim and S. Cho. “Bluetooth low energy security vulnerability andimprovement method”. In: 2016 IEEE International Conference on Consumer Electronics-Asia (ICCE-Asia). Oct. 2016, pp. 1–4. DOI: 10.1109/ICCE-Asia.2016.7804832.

[19] D. Gislason. Zigbee Wireless Networking. Pap/Onl. Newton, MA, USA: Newnes, 2008.ISBN: 0750685972, 9780750685979.

[20] T. Goodspeed. “Extracting keys from second generation zigbee chips”. In: Black HatUSA 9 (2009).

[21] W. Grange. Hajime worm battles Mirai for control of the Internet of Things. URL: https://www.symantec.com/connect/blogs/hajime- worm- battles- mirai-control-internet-things (visited on 01/02/2018).

[22] Broadband Internet Technical Advisory Group. Internet of Things (IoT) Security and Pri-vacy Recommendations A BROADBAND INTERNET TECHNICAL ADVISORY GROUPTECHNICAL WORKING GROUP REPORT. URL: http : / / www . bitag . org /documents/BITAG_Report_-_Internet_of_Things_(IoT)_Security_and_Privacy_Recommendations.pdf (visited on 01/02/2018).

[23] A. Gupta and K.Rana. “Assessment of Various Attacks on Aodv In Malicious Environ-ment”. In: September (2015), pp. 4–5.

[24] S. Hegenderfer. Get ready for Bluetooth mesh! | Bluetooth Technology Website. URL: https://blog.bluetooth.com/trashed (visited on 03/08/2017).

[25] R. Heydon N. Hunn. Bluetooth Low Energy. 2012, pp. 176–207. ISBN: 9780132888363. URL:https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx.

[26] International Telecommunication Union. “Short range narrow-band digital radiocom-munication transceivers – PHY and MAC layer specifications”. In: Itu-T (2012), p. 117.

[27] D. Song J. Newsome R. Shi and A. Perrig. “The Sybil Attack in Sensor Networks: Anal-ysis and Defenses”. In: Proceedings of IEEE International Conference on Information Pro-cessing in Sensor Networks (IPSN). Apr. 2004. URL: http://www.netsec.ethz.ch/publications/papers/newsome_shi_song_perrig_sybil.pdf.

[28] M. Iorga J. Parker and T. Karygiannis. “Secure Routing and Intrusion Detection in AdHoc Networks”. In: PerCom (2005).

[29] R.G. Mennecke J. Uher and B.S. Farroha. “Denial of Sleep attacks in Bluetooth LowEnergy wireless sensor networks”. In: MILCOM 2016 - 2016 IEEE Military Communica-tions Conference (2016), pp. 1231–1236. DOI: 10.1109/MILCOM.2016.7795499. URL:http://ieeexplore.ieee.org/document/7795499/.

81

Bibliography

[30] Y. Chen J. Yang and W. Trappe. “Detecting sybil attacks inwireless and sensor networksusing cluster analysis”. In: 2008 5th IEEE International Conference on Mobile Ad Hoc andSensor Systems. Sept. 2008, pp. 834–839. DOI: 10.1109/MAHSS.2008.4660139.

[31] A. Jason. The basics of information security: understanding the fundamentals of InfoSec intheory and practice. Syngress, 2014.

[32] J. Jonsson. “On the security of CTR+CBC-MAC”. In: Selected Areas in Cryptography. 9thAnnual International Workshop, SAC 2002. Revised Papers (Lecture Notes in Computer Sci-ence Vol.2595) Ccm (2003), pp. 76–93.

[33] B.K. Joshi. “Security Assessment of AODV Protocol under”. In: (2016), pp. 173–177.

[34] C. Karlof. “Secure routing in wireless sensor networks: attacks and countermeasures”.In: Ad Hoc Networks 1.2-3 (2003), pp. 293–315. ISSN: 15708705. DOI: 10.1016/S1570-8705(03)00008- 8. URL: http://linkinghub.elsevier.com/retrieve/pii/S1570870503000088.

[35] Z. Kasiran and J. Mohamad. “Throughput Performance Analysis of the Wormhole andSybil Attack in AODV”. In: (2014), pp. 81–84.

[36] T. Kaur. “Defending MANETs against Flooding Attacks for Military Applications un-der Group Mobility”. In: (2014), pp. 6–8.

[37] S. Raza L. Wallgren and T Voigt. “Routing attacks and countermeasures in the RPL-based internet of things”. In: International Journal of Distributed Sensor Networks 2013(2013). ISSN: 15501329. DOI: 10.1155/2013/794326.

[38] K. Laeeq. “RFAP , A Preventive Measure against Route Request Flooding Attack inMANETS”. In: (2012).

[39] G. Lee, L.Gunhee, K. Jaesung, Y. Dong-kyoo, Y. SungHyun, and M. Yoon. “An approachto mitigating sybil attack in wireless networks using zigBee”. In: Advanced Communica-tion Technology, 2008. ICACT 2008. 10th International Conference on. Vol. 2. IEEE. 2008,pp. 1005–1009.

[40] B. Lewis. Bluetooth’s third trick – Mesh networking for IoT - IoT Design. URL: http ://iotdesign.embedded-computing.com/articles/bluetooths-third-trick-mesh-networking-for-iot/ (visited on 03/08/2017).

[41] H. Samavati M. Salehi and M. Dehgan. “Evaluation ofDSR Protocol under a New Blackhole Attack”. In: (2012), pp. 640–644.

[42] W. Müller M. Stigge H. Plötz and J.P. Redlich. “Reversing CRC - Theory and Practice”.In: HU Berlin Public Report May (2006), pp. 1–3.

[43] V. Mahajan, M. Natu, and A. Sethi. “Analysis of wormhole intrusion attacks inMANETS”. In: MILCOM 2008 - 2008 IEEE Military Communications Conference. Nov.2008, pp. 1–7. DOI: 10.1109/MILCOM.2008.4753176.

[44] S. Malladi, J. Alves-Foss, and R.B. Heckendorn. On preventing replay attacks on securityprotocols. Tech. rep. IDAHO UNIV MOSCOW DEPT OF COMPUTER SCIENCE, 2002.

[45] S. Marti, T.J. Giuli, K. Lai, and M. Baker. “Mitigating Routing Misbehavior in MobileAd Hoc Networks”. In: (2000), pp. 255–265.

[46] L. Mejaele and O. Ochola E. “Analysing the Impact of Black Hole Attack on DSR-basedMANET : The Hidden Network Destructor”. In: (2015), pp. 140–144.

[47] T. Nadu and K.K Varshney. “Performance Analysis of Malicious Nodes in”. In: 978(2014).

[48] Wolfgang Osterhage. Wireless security. CRC Press, 2011.

[49] P. Ahuja R. Ahuja A.B. Ahuja. “Performance Evaluation and Comparison of AODV andDSR Routing Protocols in MANETs Under Wormhole Attack”. In: (2013), pp. 699–702.

82

Bibliography

[50] Sally. R. How to find information: a guide for researchers. 2004. DOI: Maidenhead :OpenUniversityPress.

[51] T. A. Ramrekha, G. P. Millar, and C. Politis. “A model for designing scalable and ef-ficient adaptive routing approaches in emergency Ad hoc communications”. In: 2011IEEE Symposium on Computers and Communications (ISCC). June 2011, pp. 916–923. DOI:10.1109/ISCC.2011.5983959.

[52] M. Rmayti, Y. Begriche, R. Khatoun, L. Khoukhi, and D. Gaiti. “Flooding Attacks De-tection in MANETs”. In: (2015).

[53] T. Rosa. “Bypassing Passkey Authentication in Bluetooth Low Energy.” In: IACR Cryp-tology ePrint Archive (2013), pp. 2–4. URL: http://eprint.iacr.org/2013/309.pdf.

[54] M. Ryan. “Bluetooth: With Low Energy Comes Low Security”. In: Presented as part ofthe 7th USENIX Workshop on Offensive Technologies. Washington, D.C.: USENIX, 2013.URL: https://www.usenix.org/conference/woot13/workshop-program/presentation/Ryan.

[55] L. Wallgren S. Raza and T. Voigt. “SVELTE : Real-time intrusion detection in the Internetof Things”. In: May 2013 (2014). DOI: 10.1016/j.adhoc.2013.04.014.

[56] B. Van Salve and L. Ragha. “AODV Based Secure Routing Algorithm against SinkholeAttack in Wirelesses Sensor Networks”. In: (2015).

[57] P. Sarkar, C. Kar, B. Sen, and K. Sharma. “Sensitivity Analysis on AODV with Worm-hole Attack”. In: October (2016), pp. 803–807.

[58] D.M. Shila and T. Anjali. “Defending Selective Forwarding Attacks in WMNs”. In:(2008), pp. 96–101.

[59] Bluetooth SIG. Adopted Specifications. 2017. URL: https://www.bluetooth.com/specifications/adopted-specifications (visited on 02/10/2017).

[60] A.P.R. da Silva et.al. “Decentralized Intrusion Detection in Wireless Sensor Networks”.In: (2005), pp. 16–23.

[61] C.Y Tseng, P. Balasubramanyam, C. Ko, R. Limprasittiporn, J. Rowe, and K.Levitt. “Aspecification-based intrusion detection system for AODV”. In: Proceedings of the 1stACM workshop on Security of ad hoc and sensor networks. ACM. 2003, pp. 125–134.

[62] J. Warren. IoT Security Is A Mess That Will Take An Age To Fix. URL: https://www.forbes.com/sites/justinwarren/2016/10/21/iot-security-is-a-mess- that- will- take- an- age- to- fix/2/#459be99315ae (visited on01/02/2018).

[63] Why Z-Wave Kernel Description. http://z-wave.sigmadesigns.com/why-z-wave/. Accessed: 2017-03-20.

[64] H. Williams. How to keep your baby monitor safe from hackers. 2017. URL: http://www.madeformums.com/news-and-gossip/how-to-keep-your-baby-monitor-safe-from-hackers/36235.html (visited on 01/11/2018).

[65] A.Perrig Y.C Hu and D.B. Johnson. “Packet Leashes : A Defense against WormholeAttacks in Wireless Networks”. In: 00.C (2003), pp. 1976–1986.

[66] Zigbee Alliance. “Zigbee Specification”. In: Zigbee Alliance website r21 (2015), pp. 1–604.

[67] T. Zillner and S. Strobl. ZigBee Exploited The Good, The Bad, And The Ugly. Youtube.Dec. 29, 2015. URL: https://youtu.be/9xzXp-zPkjU?t=30m10s.

[68] T. Zillner and S. Strobl. ZigBee exploited: The good the bad and the ugly. 2015.

[69] Z-Wave. “Software Design Specification Security 2 Command Class, version 0.9”. In:(2016). URL: http://z- wave.sigmadesigns.com/wp- content/uploads/2016/08/SDS11274-15-Security-2-Command-Class-version-0_9.pdf.

83