Linköpings universitet
Linköping University | Department of Computer science
Master 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 reaktivt
ad-hoc routing protokoll
Tony Fredriksson
Niklas Ljungberg
Supervisor : Marcus Bendtsen Examiner : Nahid Shahmehri
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år frå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 enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att 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 i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt 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 eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida 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 to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot 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 measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c
Tony Fredriksson Niklas Ljungberg
Abstract
Using low energy devices to communicate over the air presents many challenges to reach security as resources in the world
of Internet Of Things (IoT) are limited. Any extra overhead
of computing or radio transmissions that extra security might add affects cost of both increased computing time and energy consumption which are all scarce resources in IoT. This thesis details the current state of security mechanisms built into the commercially available protocol stacks Zigbee, Z-wave, and Bluetooth Low Energy, and collects implemented and proposed solutions to common ways of attacking systems built on these
protocol 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, and
hello flood. An intrusion detection system is proposed to detect
sinkhole, selective forwarding, and sybil attacks in the routing protocol present in the communication stack Rime implemented
in the operating system Contiki. The Sinkhole and Selective
forwarding mitigation works close to perfection in larger lossless networks but suffers an increase in false positives in lossy
environments. The Sybil Detection is based on Received Signal
Strength and strengthens the blacklist used in the sinkhole and selective forwarding detection, as a node changing its ID to avoid the blacklist will be detected as in the same geographical position as the blacklisted node.
Acknowledgments
We would like to thank Linköping University for providing us with the necessary tools to conduct 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 and Lisa Nilsson for supporting throughout the thesis.
Contents
Abstract iii
Acknowledgments iv
Contents v
List of Figures vii
List of Tables ix List of Abbreviations x 1 Introduction 1 1.1 Motivation . . . 1 1.2 Aim . . . 2 1.3 Delimitations . . . 2 2 Theory 4 2.1 Background . . . 4 2.2 Network Topologies . . . 4 2.3 Security . . . 6 2.4 Attacks . . . 8 2.5 Bluetooth . . . 15 2.6 ZigBee . . . 20 2.7 Z-Wave . . . 25
2.8 Intrusion Detection Systems . . . 32
2.9 Contiki . . . 34
3 Method 39 3.1 Literature study . . . 39
3.2 Intrusion Detection System in practice . . . 40
3.3 Experiment setup . . . 52
4 Results 54 4.1 Sinkhole and Selective forwarding detection and prevention results . . . 54
4.2 Sybil detection results . . . 65
5 Discussion 70 5.1 Results . . . 70
5.2 Method . . . 76
5.3 The work in a wider context . . . 78
List of Figures
2.1 The three common network topologies . . . 5
2.2 Example of a ZigBee mesh network . . . 5
2.3 MITM attack concept. . . 8
2.4 Sinkhole bidirectional example . . . 11
2.5 Wormhole attack example . . . 12
2.6 Sybil attack example . . . 14
2.7 BLE4.0 frame format . . . 16
2.8 BLE legacy pairing methods . . . 17
2.9 BLE Secure Connections Just Works and Numerical Comparison. . . 18
2.10 BLE General authenticated message . . . 19
2.11 ZigBee stack network model . . . 21
2.12 ZigBee frame setup . . . 22
2.13 Z-Wave stack network model . . . 26
2.14 Z-Wave frame setup . . . 27
2.15 Rime communication primitives . . . 36
2.16 Example of two applications using rime . . . 37
3.1 Architecture of the IDS . . . 42
3.2 Hidden node problem . . . 44
3.3 IDS state machine of incoming packages . . . 46
3.4 IDS state machine of outgoing packages . . . 47
3.5 Distribution of data points . . . 48
3.6 Distribution of data points . . . 48
3.7 RSSI-estimation error . . . 49
3.8 Error in estimation of standard deviations . . . 49
3.9 Common distribution of signal ratios . . . 49
3.10 Setup of the sybil Impersonator environment . . . 50
3.11 RSSI-distribution before attack . . . 50
3.12 RSSI-distribution during attack . . . 51
3.13 Simulated network setup . . . 52
4.1 Sinkhole detection result graphs . . . 57
4.2 Selective Forwarding detection result graphs . . . 60
4.3 Sinkhole and selective forwarding detection with prevention enabled result graphs 64 4.4 Distribution of 38000 RSSI data points . . . 65
4.5 Sybil reports/message . . . 66
4.6 Setup for impersonation attack . . . 66
4.7 Deviations during sybil Attack . . . 66
4.8 Sybil node impersonator . . . 66
4.9 Sybil node unsuccessful impersonator . . . 67
4.10 False positive sybil environment . . . 67
4.12 Proximity reports during a sybil attack . . . 69 5.1 Example of overlapping RSSI-areas . . . 75
List of Tables
2.1 Voting attack timing windows . . . 14
2.2 Bluetooth PHYs, modulation, coding and data rate. . . 16
2.3 Bluetooth security conclusion table . . . 20
2.4 ZigBee difference overview . . . 21
2.5 ZigBee security conclusion table . . . 25
2.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 . . . 55
4.2 Sinkhole true and false positives, without IDS prevention, lossless . . . 55
4.3 Payload delivery ratio without IDS prevention, lossy . . . 56
4.4 Sinkhole detection without IDS prevention, lossless . . . 56
4.5 Sinkhole true and false positives, without IDS prevention, lossy . . . 56
4.6 Payload delivery ratio, sinkhole attack, without IDS prevention, lossy . . . 57
4.7 Selective Forwarding detection without IDS prevention, lossless . . . 58
4.8 Selective Forwarding true and false positives, without IDS prevention, lossless . . 58
4.9 Payload delivery ratio without IDS prevention, lossless . . . 58
4.10 Selective Forwarding detection without IDS prevention, lossy . . . 59
4.11 Selective Forwarding true and false positives, without IDS prevention, lossy . . . . 59
4.12 Payload delivery ratio without IDS prevention, lossy . . . 59
4.13 Sinkhole detection with IDS prevention, lossless . . . 61
4.14 Sinkhole true and false positives, with IDS prevention, lossy . . . 61
4.15 Selective Forwarding detection with IDS prevention, lossless . . . 61
4.16 Selective Forwarding true and false positives, with IDS prevention, lossless . . . . 62
4.17 Payload delivery ratio with IDS prevention, lossless . . . 62
4.18 Route flush commands, lossless . . . 62
4.19 Sinkhole detection with IDS prevention, lossless . . . 62
4.20 Sinkhole true and false positives, with IDS prevention, lossy . . . 63
4.21 Selective Forwarding detection with IDS prevention, lossy . . . 63
4.22 Selective Forwarding true and false positives, with IDS prevention, lossless . . . . 63
4.23 Payload delivery ratio with IDS prevention, lossy . . . 63
4.24 Route flush commands, lossy . . . 63
5.1 Sinkhole true detection comparison with SVELTE, lossless . . . 71
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
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
1
Introduction
1.1
Motivation
Devices in the Internet of Things (IoT) have lately repeatedly made headlines due to security breaches where private information is leaked or devices being taken over and included into bot networks. For instance teddy bears equipped with microphones and speakers, intended for far away parents to talk to their children, could be hacked to say whatever the attacker wished or any audio that passes through it could be intercepted and downloaded. Baby monitors have also been reported to be hacked, sending video and audio from the source or playing messages sent by the attacker [64]. There are large botnets created by worms such as Hajime and Mirai that take access over IoT-devices using default login details and brute forces their way to control of each device [21].
There are many reasons security has been dismissed in the IoT. Time to market being one of them, as implementing security takes time which allows a competing company beat them to the market. Time is money and security can be seen as adding no value to the actual product, only overhead. Security also takes space both in transmission overhead, but also valuable space due to more lines of code creating larger files after compilation on hardware constrained devices, meaning a secure product might require a higher price tag which can make it harder to sell than a the same product without security as it will have both a cheaper development cost and a cheaper hardware cost [62].
Before choosing which technology and protocol to use in a device for any application the security question requires attention as some protocols do not provide access to the security that is deemed necessary while others have it as an opt-in feature which the developer must be aware of when creating secure applications.[22] To ease the process of finding out what security can be expected from the different protocols this report has been produced. It is useful for realizing the potential security flaws of a system already in production or give insight about what to consider during the development cycle.
There are many scenarios where an intrusion detection system (IDS) is necessary to ensure the function of systems critical to peoples health or buildings. Imagine a scenario where a factory has its smoke detectors set up in a wireless multihop network that is supposed to automatically alert the fire department when smoke is detected. If a malicious attacker gets a hold of just one node it can in the worst case send out messages that will make all network traffic pass through it, creating congestion, and it might even drop all the packages that are
1.2. Aim
supposed to reach a node with the ability to contact the fire department. During the day, the delay in getting the fire department to the scene might result in heavier structure damage and death of employees, or during the night the alarm might never come or come too late which might 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 protocols Zigbee, 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 base for developing parties to create secure devices. Information about security is scattered all over multiple specifications, scientific reports and videos of talks from security conferences all over the world. This thesis aims to collect key information and gathering it in one place to reduce time needed to get started on choosing technology and beginning to implement it. Implementing the sinkhole, selective forwarding, and sybil detection aims to create an understanding of the feasibility and problems when implementing security on those low performance devices and show how fragile ad hoc mesh networking is at its core without security.
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 network
protocols 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 wireless network 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 extracencryp-tion/eavesdropping, replay/playback attack, denial of service, denial of sleep, 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 was not 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 hardware was used to test the solution in a real world environment.
1.3. Delimitations
• The protocol to evaluate was only a variant of the reactive AODV, ad-hoc on demand distance vector, routing protocol.
• The network environment the IDS was evaluated on was static, i.e. no mobility of the nodes.
• The hardware resources on the nodes are limited in terms of processing power, memory and wireless bandwidth.
• The attackers are presumed to be included in the network, and no end-to-end encryp-tion soluencryp-tion is available due to the complexity it adds to managing.
2
Theory
2.1
Background
During the early years of the Internet the majority of the connected devices were computers which purpose was either military or scientific and the number of connected devices were in the hundreds. Since then the Internet has grown in a very rapid pace with approximately 500 million devices in 2003 to 12.5 billion devices connected to the Internet in 2010 [15]. The telecoms manufacturer Ericsson predicts 50 billion devices to be connected in 2020 [13]. The rapid growth of connected devices has started a new era where people connect almost any-thing and everyany-thing 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 to Gbit/s speeds and ranges of up to hundreds of meters. One of the big downsides of the WLAN is that it consumes much energy and many times, the wide transmission/reception range is not necessary. Therefore the need of a smaller range and less energy consuming network 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 of IEEE 802.15 where there are ten major areas of development, among others, Bluetooth and Low 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 have started 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.1 shows. In the star topology the edge nodes send data to one central node. In the IoT this central node probably has more computing power and maybe an Internet connection. The tree topology is a hierarchical architecture where messages are passed up the tree towards the root until a node recognizes the message is for one of its descendants, after which it sends it downwards towards the destination. The mesh topology’s strengths are clear in a situation where the network is changing. Nodes may move or paths become unavailable
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 each other adds robustness to the network. Different implementations of the mesh topology work differently, 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 network structure also opens up for devices to be more energy efficient as the transmission power can be reduced to only reach the closest neighboring router which routes the message further into the network.
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 security are authentication and authorization.
Here confidentiality is tightly coupled with privacy and secrecy and to keep information secret to unauthorized entities that should not have access to it. Confidentiality is most of the time achieved by cryptography using encryption to make information unreadable for all entities lacking the correct decryption key.
Integrity is based on the concept that information should not be able to be tampered with by 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 informaauthentica-tion is not correct, the integrity of the informaauthentica-tion can not be verified and the information can not be deemed trustworthy.
Availability is based on the concept that information or services should be available when needed. Availability can be achieved by ensuring the system serving the information is robust and 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 decrypencryp-tion. Asym-metric encryption, or public key cryptography (PKC), instead has a key pair, one key for encryption 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 decrypt the data. Symmetric cryptography has both major pros and cons. The biggest pros are that it generally has larger throughput compared to asymmetric cryptography and it needs smaller keys to achieve the same security. One of the biggest cons for symmetric cryptography is that 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 has to 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 be used in combination with PKC. According to NIST, there are only two approved symmetric encryption algorithms which is the Advanced Encryption Standard (AES) and Triple Data Encryption 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 can be used in different modes of operation depending on what the requirements of the system it is implemented in. Different modes of operation can require one or more encryption keys to be used depending on if it should be used for encryption only, integrity/authentication only or encryption and integrity/authentication together [1]. The modes of operation accepted by NIST is
• ECB: Electronic Code Book. Each clear text block translates to the same cipher text block regardless of content encrypted before. This mode requires only one encryption key 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 cipher-text block to be encrypted. The whole clear text is then fed through this chain until all is encrypted. Thanks to the feedback of the cipher text, each cipher text block will be different even if the clear text, at least if the
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. This IV 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 text after the encryption is done and then feds output as next step. CFB also need an IV and one encryption key.
• OFB: Output feedback. OFB takes the output of the encryption and feeds it to the next block encryption. At the same time, the same output gets XORed with the clear text to generate 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 block encryption operations. CTR instead uses a nonce, much like the IV, appended to a integer counter that is encrypted and then XORed with the clear text to generate the cipher text. Since this mode does not make a stream that relies on earlier blocks being encrypted, it can be parallelized which makes throughput higher than the other. CTR needs one nonce and one encryption key.
• CCM: CTR mode with Counter with Cipher-Block-Chaining with Message Authentica-tion Code (CBC-MAC) is a combinaAuthentica-tion of CTR and CBC with message authenticaAuthentica-tion code. 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 key and 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 the year of 2030 [3].
Asymmetric encryption
There are several different asymmetric encryption schemes that can either provide encryp-tion and decrypencryp-tion or encrypencryp-tion only, mostly used to exchange common secrets between two or more parties. Asymmetric encryption, or public key cryptography, is often used to encrypt and transport keying material to be used for symmetric encryption over insecure transport mediums. PKC uses significantly larger keys compared to symmetric encryption to achieve the same security, and PKC is not made to encrypt larger data streams as symmetric encryption is.
The common PKC schemes are
• RSA: RSA is an encryption scheme with support for decryption as well. RSA relies on using large prime numbers that is multiplied with the clear text. The RSA is built upon the hardness to factor large prime numbers.
• Elliptic Curve Cryptography (ECC): ECC is based on the algebraic structure of elliptic curves over finite fields and requires smaller encryption keys, logarithmic compared to RSA or other discrete logarithm based schemes. This is due to the mathematical properties of the elliptic curve. ECC is also more efficient than RSA and other discrete logarithm based schemes with makes it suitable for contained devices with security requirements.
• Diffie Hellman (DH): The Diffie Hellman scheme can be implemented in many different PKC schemes. The main principle in DH is that two parties start with an own secret key and a number booth know. Booth parties then encrypts number both know with their secret key and sends the encrypted version to the other part. Both parts then encrypts the received message again with their own private key to reach the same common se-cret.
2.4. Attacks
To achieve high security, key sizes of at least 3,072 bits should be used for RSA and 256 bits for ECC. Information encrypted with those bit sizes are considered to be secure beyond the year 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. The attack can be either passive or active. When it is passive, the attacker only saves and relays the information. When active, the attacker can manipulate the data being sent between the parties.
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 sent and/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 messages being sent, Eve would not be able to read what the messages say. On the other hand, Eve could still be able to intercept the key exchange messages and manipulate the messages if she were to find out the encryption key. The way to mitigate this problem is to make sure the authenticity of whom you are talking to. As such Alice and Bob would have to authenticate one another. If Alice could find a way to communicate with Bob and be sure that only Bob would be able to read or create messages for communication between them, then Eve would have no way of reading the messages or manipulate them. The mitigation strategy for MITM attacks is to authenticate who you are talking to and make sure that only that party can read the messages you want them to read and then make sure that the messages are being sent encrypted 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 placed in hard to reach places, intended only to be maintained once every few years. To achieve such long battery time, the device can turn off its transmitter and receiver when not transmitting or receiving. 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
2.4. Attacks
drain its battery, severely damaging its battery life.[29] Denial of Sleep (DOSl) attacks are similar 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 environment a DOSl attack can for instance drain the battery of motion detectors to enable a home invader to enter property without being detected. Jonsson conducts experiments on the Power Con-sumption of Wireless sensor networks (WSN), testing cyclic sleep scenarios on BLE, Zigbee and ANT Sensor nodes [32]. The experiments show a huge difference, one to two orders of magnitude, between a high and low duty cycle, where duty cycle is the average awake time divided by total time per cycle. These reasons suggest using protection techniques against DOSl attacks is important.
Replay/Playback/Delay attack
In a replay/playback/delay attack, an attacker listens in on the radio medium and records a heard message sent from a device. It can then at a later time replay it as it was heard, and if there exist no security mechanisms, the receiving device will think that the sent message was sent by a legit node. A way to amplify the attack would be to jam the radio medium so the message is not received by the intended receiver and at a later point replay the message, as it would have been sent the first time, this being the delay attack. A scenario for this attack would be a network with a wireless door lock. A malicious attacker could listen in when a unlock command was sent. At a later point the malicious attacker could replay the heard message, 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 the encryption key provisioning scheme, or is able to physically extract encryption keys from a captured device. Many of the key provisioning protocols send out the network encryption key in plain text upon network inclusion. A malicious attacker could thus, if present during this 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 the RAM 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. Bluetooth is 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 compromised node can be used to deny the service of multiple nodes [37]. This subsection begins with a short 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 entire space of attack-vectors that are prominent on the web. In this section the network connected gateway is assumed to be uncompromised and as such no attacks on a WSN originating from base stations are discussed.The routing description is followed by a list of common general risks 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 another entity in the network. The initiating device checks its routing table, later described, and if it 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
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 updates its routing table. The RREP message is propagated back until it reaches the original RREQ sender. 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 route error (RERR) message is sent notifying the source node that a new route discovery process needs 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 route is.
Dynamic Source Routing
Dynamic source routing (DSR) is a proactive routing protocol that relies on routes being setup before the need to use them. This results in every node, or a network controller, needs to have a complete routing table with routes to every node, and it must know the neighbors of every node to be able to construct routes. In contrary to AODV, DSR sends the complete route with its packages leaving more routing overhead. On the other hand, since every route should be setup 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 node can 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 malicious node 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 test that the routing graph is still correct, the routing graph Information Object, are forwarded with 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 to create entirely disjoint paths. Using dynamic paths can also help, oftentimes there are paths that are nearly as efficient as the original path in the destination oriented directed asyclic graph (DODAG). Many attacks are easily subverted by encryption which makes the rout-ing messages indistrout-inguishable 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 lost messages 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 path to the destination node or gateway available. When the packets arrive for forwarding the attacker has full control of what to do with it. A sinkhole attack on its own is in most cases not too detrimental to the WSN service, but combined with other attacks it can bring down an entire network. Nodes that rely exclusively on internal mechanisms to determine their paths are immune to sinkhole attacks as the malicious node cannot change any other nodes path. Using multiple DODAG instances allows for an IDS, located in the base station/sink or some 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
2.4. Attacks
Figure 2.4: The red node broadcasts overstates its routing to all available nodes with large transmitter power as indicated by the blue circle. The ones in range to reply are indicated by the purple circle.
another is supposed to be closer to the root, might be later rejected by the routing protocol as 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 the attacker, the attacker may instead use a high transmission powered device such as a laptop to spoof a node. The laptop outclasses all other sensors in performance, radio transmission and 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 directionality checks or self healing mechanisms are required to maintain the network. Without any such mechanism, the network might break without malicious activity simply due to a difference in 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 latency technique 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 node may provide such a good path to the root that all nearby nodes use it. This way the wormhole will become a sinkhole and can be combined with some other type of attack, be it selective forwarding or eavesdropping. The wormhole attack can be combined with a sybil attack to reduce 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 first instance of a message it will receive, and ignore other messages of that type. The attacker can utilize 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 race conditions exist, encryption and authentication does not thwart the attack as the messages are unmodified. If the wormhole has the fastest way to forward a message from one node to another, 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 Condition attacks attempt to confuse the nodes in the network as to how the topology looks. Another way of confusing the network is by constantly forwarding messages between nodes through the wormhole, making them think they are neighbors.
2.4. Attacks
Figure 2.5: The wormhole attacks allows the orange nodes to provide the best possible/equal path 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 network by considering delay. Using a delay statistic an IDS can find incompatible hop delays and end-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 detected when a node is supposed to use only a few jumps but the time it takes indicates there are hops being made that were not advertised. A node that transmits over nodes that are part of the wormhole may also experience unexplained traffic congesting and slowing down its transmissions. As such the end to end delay will increase for nodes that are not part of the wormhole. 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. Each message is extended with the current time and the position of the transmitting node. The receiving node calculates the distance between the two using its own estimation of time and position and compares it to an upper bound for normal communication. If messages travel over the threshold a wormhole can be suspected. wormholes that relay data between two nodes that are geographically close but with an interfering obstacle between them will not be detected. 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 the current time. The receiving node compares its current time to time attached to the message. If the time difference is above a threshold the message is disregarded. The message could also be built with an expiration time instead. Both of these solutions assume that messages are properly 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 claimspoof-ing to be at two places at once, as a receiving node may calculate the validity of how much another node claims to have moved. A benign node may rebroadcast the fraudulent messages to convince neighbors that a node belongs to an attacker.
Sybil Attack
A sybil attack is when a single node in the network forges multiple identities. Remembering the technique from selective forwarding of trying to build multiple paths to the root, the effects of a sybil attack are considered. If node A is part of the first, but not the second, path and B is part of the second path, the paths are not disjunct if A or B are fake nodes created by the 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 attacker copies the identity of one node to others. In the clone ID attacks you use multiple physical devices pretending to be one, in sybil one physical device makes up multiple logical devices
2.4. Attacks
[37].
Let us assume that each device in a network has a unique address, a sybil node may pick a 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 way out 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 long time by pretending to leave the network and that new nodes arrive. This might circumvent simple methods that blacklist devices that act suspicious by refreshing the active sybil nodes identities.
Yang et al. in [30] propose a general RSS based sybil detection mechanism. They use a statistical approach in which each point available to record the signal strength received from different nodes does so. When each recording device combines their data an N-dimensional point is created. Multiple points from the same node should be in the same area, while other nodes should be in a different physical position. The detection mechanism was in their setup successful but it does not study how the false positive or false negative-rates depend on the amount of recording points, clustering nodes in fewer dimensions which might be of interest for feasibility in practice. This approach assumes nodes are still in regards to their environment. Using an RSS-based approach to detecting sybil attacks limits the users ability to place devices close to each other. Devices must have a minimum distance from each other to not trigger the a sybil attack detection response. The authors do test this and conclude that when devices have a greater minimum distance between them the chance for false positives diminish.
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 of network wide challenge. For instance all nodes may a be provided a nonce which they are to use as an argument to a function. Each node must within a set time frame answer with the correct response. Any node that does not succeed becomes less trusted, and any nodes that reach a threshold are kicked out of the network. This is intended to work by using the fact that one node will not have time to compute the correct answer for all its nodes and as such the network will build an understanding of sybil nodes in the network. Of course this has a drawback in that nodes must calculate and transmit messages with no relation to their specific purpose, decreasing the devices battery life. A device creating sybil identities might not be on an equal playing field as the devices it is impersonating in regards to computation power. For instance a captured node might be replaced by a computer with high enough capability to calculate and respond to multiple challenges, especially if the device is capable of using more than one radio transmitter.
Newsome et al. [27] present a taxonomy of how a sybil attack may take form, as depicted in Table 2.1. Direct Communication is when malicious nodes use their sybil identities for communicating with legit nodes. Indirect communication instead means that the malicious node presents the sybil node as one of its neighbors rather than announcing itself under a new identity. They also present some concrete examples of defenses, such as Radio Resource testing, where a node decides to verify some other node. Using this technique the suspecting node challenges each of its neighbors to each transmit on a different channel. If the attacker has created multiple nodes and cannot transmit on all channels it is supposed to, the lack of a 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 available the captured nodes can cover all channels thus covering up for their sybil descendants. Using indirect communication can prevent legit nodes from directly challenging a sybil node, as all sybil nodes are neighbors of only malicious nodes.
2.4. Attacks
Table 2.1: Depiction of which sort of communication, identity and simultaneity. *If there is a time period during which nodes vote a non-simultaneous attack might be applicable. **When nodes can join more frequently than a node is allowed to transmit. For instance new nodes might be allowed to join every minute but the network is flooded with data only once an hour.
Communication Identities Simultaneity
Direct Indirect Fabricated Stolen Simultaneous Non-Simultaneous Distributed Storage x x x x x Routing x x x x Data Aggregation x x x x x Voting 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 which is 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 to make themselves known to neighboring nodes or to keep connections active. The receiving nodes usually assume they are in normal radio transmission range, which might not be true for a HELLO flood attack. An adversary announcing its arrival to the network with a great path to the base station might, if the transmission strength is enough, make all nodes in the network consider it as its parent. An out of reach node might realize it cannot route its messages through this neighbor any longer and try to use its local neighbors to find a new path, but if all neighbors are in the same state the network might get stuck in a state of confusion [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 RPL uses link-layer acknowledgements to verify a path. If no link-layer acknowledgements are received another route is chosen. The new path is not dismissed by the nodes which are in range of the attacker, which makes the end result a sinkhole (given that the hello message was of the type that exaggerates its capabilities to reach the base station) [37]. This is close to the suggested 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 messages. If a RREQ-message is created and transmitted asking for a route to a non-existent node in the network the message will propagate through potentially all the nodes. Consecutive transmissions of RREQ-messages may create enough useless chatter in the network to disrupt the expected services [36] suggests a clustering based reputation technique where a cluster head is chosen and used to keep track of cluster nodes’ reputation. A node that transmit too many RREQ messages gradually loses its reputation and will be disregarded. There are many different
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 by connecting cell phones and laptops/personal computers. Its main application did however appear to act as a link to send and receive audio between a cellphone and a headset. As the technology got more widespread the use areas became wider and the data rate requirements started 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 Mbps for v3.0 [25].
In December 2016 the Bluetooth 5.0 Specification was adopted by the Bluetooth Special Interest Group, (SIG), to supersede Bluetooth 4.2 which was released in December 2014. The first 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 Data Rate (BR/EDR) and Low Energy [59]. Bluetooth 5.0 is marketed as a new version with up to four 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 and brought to the Bluetooth SIG. It is designed to enable devices to be fully operational for years using a button cell battery. BLE is most commonly used in fitness products, security and proximity sensing, health and wellness as well as general smart home applications. BLE uses the 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 one of the 79 designated Bluetooth channels. BLE channels are instead 2 MHz wide and uses 40 different channels. Three of them, spread out over the available spectrum to minimize risk of crippling interference on all of them at once , are for advertisement and the other 37 are used to transmit data packages. [25] Due to the 2.4 GHz band being very crowded, Bluetooth 5.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 Primary Advertising channels, and the other channels are Secondary Advertising as well as data. This allows for beacons, simply put Bluetooth transmitters, that broadcast data rather than connect and pair with other devices to pick a channel which is not as congested as the advertisement channels are likely to become.
As noted BLE uses frequency hopping over its 37 data channels and a packet is always sent on each hop even if it contains no usable data. Frequency hopping means quickly switching carrier 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 less hard to sniff than more advanced, difficult to predict, patterns. This does not imply a random hop increment or interval gives security, as a sophisticated attacker might sniff all channels simultaneously.
A Link Layer package looks as described in Figure 2.7 and is used in both advertisement channel packets as well as in data packets. There are two differences between the package described 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 5 uses a 2 byte preamble when using LE 2M PHY. Below as well as in Figure 2.2 the differences between LE 1M, LE 2M and LE Coded PHY are described. LE 1M and LE 2M are the two LE Uncoded 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.
2.5. Bluetooth
PHY Modulation Scheme Access Header Payload Data Rate
LE 1M 1Msym/s Uncoded Uncoded 1 Mb/s
LE 2M 2Msym/s Uncoded Uncoded 2Mb/s
LE 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 Coded PHY can be error corrected with S=2, where 2 symbols are used per bit, or S=8. LE Coded PHY uses the 1Msym/s model, and therefore achieves 500 kb/s for S= 2 and 125 kb/s for S=8 [59].
Pairing Method
Before Bluetooth 4.2 there were three ways for Low Energy devices to establish a connection between each other. These three key exchange and pairing algorithms are used when at least one of the two devices predates Bluetooth 4.2. Devices of version 4.2 or 5.0 can be forced to use Secure Connections Only mode, which requires the use of a non legacy-pairing method and as such it makes the device incompatible with devices that run earlier versions of the protocol. As seen in Figure 2.8, the pairing begins with the devices exchanging their public features to decide which pairing method to use. The three available legacy pairing algorithms are
• Just Works
For 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 Entry
Displays a six digit PIN on one device and manually input into the other device, to avoid communicating the TK over the air.
• Out Of Band
Exchanges the pairing information using some other technology than Bluetooth. Out Of Band can only be used if the devices have interfaces compatible with each other, for instance near field communication. This pairing method uses a 128 bit value for its TK. Bluetooth 4.0 connections pairing contained very little protection against eavesdropping and MITM attacks [18] which may have inspired the addition of LE Secure Connections in version 4.2.LE Secure Connections uses, just as BR/EDR, the well established anonymous key agreement protocol Elliptic Curve Diffie-Hellman (ECDH) [4].
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 method they have in common which means that if a version 4.2+ device pairs with a 4.0-device it will use a Legacy Pairing method.
Attacks on Bluetooth Low Energy
Man In The Middle2319 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. According to the Bluetooth 5.0 documentation regarding the Passkey Entry "The passkey Entry method provides 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], who states that an attacker can brute force the correct passkey TK and trick the master as no matter the 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. Figure 2.9 shows how two devices may pair using LE Secure Connections Just Works and Numerical Comparison, as described by the Bluetooth 5.0 specification. Na, and Nb are nonces and Cb is 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 and BtleJuice that exploit the vulnerabilities described below.
To follow and understand a hopping connection, the eavesdropper needs to know the hop interval, hop increment, access address and Cyclic Redundancy Check (CRC) init. The access address can be determined by monitoring a data channel looking for empty packets. Empty packets are identifiable by their headers. This means the bitstream can be read, and the 32 bits before the empty packet header provides a possible access address. There are two bits in the empty-message header that change, and as such only 14 bits of the header can filtered over which generates a lot of false positives. A candidate access address that is observed multiple times 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 rejected by the receiver. A CRC is a cheap way to protect from bit errors that occur without intent such as interference or a bad cable however the CRC does not provide cryptographic integrity and can be forged quite easily. CRC should never be used as an integrity check, only as a mean to detect transmission errors [42, 59]. To get the correct CRC one must Figure out the value of CRC-init which varies between connections which is done by taking an incoming candidate package and seeding the Linear-feedback shift register with the CRC. The bits of the CRC is then fed through the LSFR in reverse order which leaves a possible init in the
CRC-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 be the CRC-init [54].
The Hop interval is easy to calculate, here in milliseconds. ∆t
1.25 ˚ hopInterval
The hop increment is recovered by receiving a message on one data channel, hop to the next and measure the time it takes before the second package arrives, and from there calculate the hop 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 time window, 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 original message or by introducing interference in the legit connection.
2.5. Bluetooth
Figure 2.10: General authenticated message.
Replay/playback attack
When fast connection setup and fast data transfer is required, authenticated unencrypted data 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 to a peer. Signing is then performed according to NIST Special Publication 800-38B. The MAC generation function is defined as: MAC = CMAC(K, M, Tlen) Where K shall be the CSRK, M shall be the message concatenated with the SignCounter. Tlen is the bit length of the MAC and shall be 64 bits. The MAC and SignCounter is applied to the message as Figure 2.10 describes. This mode is known as LE Security Mode 2. A receiving device protects itself against replay attacks by comparing previously received SignCounters with the current one and ignoring data with an outdated SignCounter.
When using LE Secure Connections to pair devices both the Initiating and Non-Initiating device generate a random nonce which is used to protect against replay attacks. New Nonces must 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/read operations, the authors were able to reduce battery time from 120 hours to just 6 hours, or a 95% decrease. Potential mitigation techniques against DOSl attacks are described in the following subsections.
Resolvable Private Addressing
Bluetooth 4.2 defines Resolvable Private Addressing (RPA) where the devices produce a hash on the form hash = ha(IRK||prand)Where IRK is the Identity Resolvement Key and prand is a random number. The address message is sent as hash||prand The receiving device should have a list of all paired devices with white listed IRKs provided after the pairing process is complete. The device tries to resolve the address by checking over its IRKs for a key that satisfies hash-received = ha(IRK||prand) where prand is extracted from the message. As such, as long as the attacker cannot find the IRK it cannot spoof a white listed device to force them to carry out operations [4].
Link Layer Device FilteringThe Link Layer has Device filtering. Devices may have poli-cies for the Advertising state, Scanning State and Initiating state. These polipoli-cies exist to min-imize the number of devices of which to respond to which is very relevant to avoid sleep denial. The filtering can be used to avoid processing scan requests, which are requests from entities in the proximity for a device to identify itself, and connection request, where a device attempts to establish a connection.
• White List The before-mentioned white list can be used on the Link Layer by the Host creating a copy of the white listed devices, the RPA is then to be resolved and checked
2.6. ZigBee
against the list before waking up the Host thus preserving resources when a non-white listed device attempts to wake it [4].
• Advertisement filter Policy Only process Scan and Connection requests from white listed 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 List
Uher et al. [29] propose a Black List as well as a White List. Every time an RPA is resolved it is added to the Black List. As long as a devices IRK is still unknown, this would mitigate the risks of a potential Spoofing Attack where the attacker takes the name of one of its RPA’s. One drawback of this is that a new RPA must be generated with 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 due to implemented security measures.
Attack\Protocol Version Bluetooth Bluetooth Bluetooth
4.0 4.2 5.0
MITM Yes No* No*
Key extraction/ Yes* No* No*
Eavesdropping
Replay/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
NoNative build in Security
No*Opt in security available
YesDirectly vulnerable
Yes*Vulnerable under specific circumstances
2.6
ZigBee
The ZigBee technology has become widely popular due to its characteristics of low power and low cost and has got a foothold in, among others, home automation and light control applications. 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 ZigZig-Bee alliance for the sake of interoperability between different manufacturers. The ZigBee specification defines a network layer 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, ZigBee is 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
2.6. ZigBee
Feature Zigbee 2006 ZigBee 2007 Zigbee Pro
Size in ROM/RAM Smallest Small Bigger
Stack Profile 0x01 0x01 0x02
Maximum hops 10 10 30
Maximum nodes in network 31 101 31 101 65 540
Mesh networking Yes Yes Yes
Broadcasting Yes Yes Yes
Tree Routing Yes Yes No
Bandwidth used by protocol Least More Most
Fragmentation No Yes Yes
Multicasting No No Yes
Source Routing No No No
Symmetric Links No No Yes
AES 128 bit Yes Yes Yes
High 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, there exists a plenitude of micro controllers and transceivers that implement the 802.15.4 standard that manufacturers can choose upon depending on demands of energy consumption and performance. 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 quick overview, as seen in Table 2.4.
There are three types of devices in a ZigBee network; the ZigBee coordinator, ZigBee router and ZigBee end device. The ZigBee coordinator is an IEEE 802.15.4 coordinator and coordinates the ZigBee network. It also houses the Trust Center (TC) which should be the device that the whole network should base its trust on. The TC should distribute and manage
2.6. ZigBee
Figure 2.12: The setup of a ZigBee frame. MAC is in this Figure refereed to as Message Authentication Code
all encryption keys used in the network. If the ZigBee network were to be controlled by a device connected to the Internet, the coordinator can also act as a gateway to the Internet converting 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 not need to be in direct range of another device to communicate with it. A ZigBee router can both act as a router and at the same time have an application specific purpose just as an ZigBee end-device.
The ZigBee end-device is a device in a ZigBee network that has an application specific purpose and does not act as neither a coordinator or a router. Since it has limited functionality and not has any further responsibilities other than its specific purpose, it can be implemented with very limited hardware demanding low energy consumption. Hence a ZigBee end-device can 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 in CCM* (a variant of Counter mode with CBC-MAC) mode with 128 bit keys. The ordinary CCM mode is a block cipher operation mode which provides both encryption and integrity but CCM* also adds functionality for encryption-only and integrity-only depending on the policy of the network. For replay protection, a frame counter is present for the network layer and one frame counter is associated for each pair of devices that have been communicating with each other. The frame counter is 32 bits long and is not to be reset unless the TC issues a new Network key. The device should drop all frames which does not have a frame counter larger than the last one received to ensure message freshness and that the frame has not been replayed by an attacker.
There are two kinds of AES keys in the ZigBee 3.0 [66] specification which are a Network Key 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 at the Network layer. The other kind of key is called a Link Key and is used between two devices 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 with a default key specified in the specification. If the key used is the default one, an attacker
