Enabling Bluetooth Low Energy auditing through synchronized tracking of multiple connections

Accepted Manuscript

Enabling Bluetooth Low Energy auditing through synchronized tracking of multiple connections Jose Gutierrez del Arroyo, Jason Bindewald, Scott Graham, Mason Rice PII: DOI: Reference:

S1874-5482(17)30051-3 10.1016/j.ijcip.2017.03.006 IJCIP 218

To appear in:

International Journal of Critical Infrastructure Protection

Received date: Revised date: Accepted date:

9 January 2017 9 March 2017 12 March 2017

Please cite this article as: Jose Gutierrez del Arroyo, Jason Bindewald, Scott Graham, Mason Rice, Enabling Bluetooth Low Energy auditing through synchronized tracking of multiple connections, International Journal of Critical Infrastructure Protection (2017), doi: 10.1016/j.ijcip.2017.03.006

This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

ACCEPTED MANUSCRIPT

Enabling Bluetooth Low Energy auditing through synchronized tracking of multiple connections

CR IP T

Jose Gutierrez del Arroyo, Jason Bindewald, Scott Graham, Mason Rice1

Department of Electrical and Computer Engineering, Air Force Institute of Technology, Wright-Patterson Air Force Base, Ohio 45433, USA

AN US

Abstract

AC

CE

PT

ED

M

Bluetooth Low Energy is a wireless communications protocol that is increasingly used in critical infrastructure applications, especially for inter-sensor communications in wireless sensor networks. Recent security research notes a trend in which developers and vendors have opted out of implementing Bluetooth Low Energy link security in many devices, enabling protocol attacks and attack frameworks. To help defend devices with no link security, researchers recommend the use of Bluetooth Low Energy traffic sniffers to generate auditable communications logs. Unfortunately, current sniffers can only follow a single connection at a time, and some are ineffective at capturing long-lived connections due to synchronization problems. These limitations make current sniffers impractical for use in wireless sensor networks. This paper presents Bluetooth Low Energy Multi (BLE-Multi), a firmware enhancement to the open-source Ubertooth One that enables the sniffing of multiple simultaneous long-lived connections. To increase the capture effectiveness for long-lived connections, a novel synchronization mechanism is proposed that uses transmissions of empty packets to infer information about connection timing. Multi-connection sniffing is achieved by opportunistically switching between connections as they move from the active to inactive state, which is an inherent function in Bluetooth Low Energy to help conserve energy. The experimental evaluations demonstrate that BLE-Multi simultaneously captures multiple active connections while outperforming Ubertooth One when it captures a single connection, paving the way for the development and implementation of automated defensive tools for Bluetooth Low 1

Corresponding author: Mason Rice ([email protected])

Preprint submitted to IJCIP

March 31, 2017

ACCEPTED MANUSCRIPT

Energy and wireless sensor networks.

CR IP T

Keywords Bluetooth Low Energy; Wireless Sensor Networks; Wireless Security; Traffic Sniffers

Submitted: January 9, 2017; Revision: March 9, 2017; Accepted: March 12, 2017

AN US

1. Introduction

AC

CE

PT

ED

M

Bluetooth Low Energy (BLE) is a wireless communications protocol that is widely used in applications that leverage its low implementation overhead, minimal energy consumption and mesh routing capabilities [2]. In the critical infrastructure, Bluetooth Low Energy is a leading protocol for inter-sensor communications in wireless sensor networks [15]. Wireless sensor networks comprise decentralized wireless sensors that collaborate to detect physical phenomena and communicate findings to a central node [7]. Inter-sensor communications are normally achieved via the application of mesh routing algorithms, where each sensor acts as a network hop. With the mesh routing capabilities available in Bluetooth Version 4.2 [3] and the introduction of viable multi-hop algorithms [9, 11, 17], a number of wireless sensor networks have turned to Bluetooth Low Energy as an inter-sensor communications protocol for applications ranging from in-hospital medical monitoring [18] to environmental monitoring [9]. Outside of wireless sensor networks, vendors already use Bluetooth Low Energy in critical infrastructure applications that combine computational capabilities with physical processes, mainly in building security and automation. For example, Bluetooth Low Energy door locks provide access control mechanisms that are easy to deploy and manage [5]. Bluetooth Low Energy temperature and humidity monitors, airflow measurement tools and compressed air pressure sensors provide wireless access to key metrics pertaining to heating, ventilation and air conditioning systems. Attacks on these types of systems can impact the operations of an organization, the security of its assets and the safety of its employees [14]. While the Bluetooth Low Energy specification [3] defines security mechanisms for link layer encryption, authentication and data integrity, developers 2

ACCEPTED MANUSCRIPT

PT

ED

M

AN US

CR IP T

often ignore these mechanisms, leaving link layer communications completely unprotected. Published attack frameworks exploit this general lack of security to hijack connections, steal private information [4, 16], inject fake data into critical systems [12] and bypass physical building security by remotely opening door locks [21]. While built-in security mechanisms should always be the first line of defense, added layers of security, oversight and risk management can help protect Bluetooth Low Energy devices that are already in use. One way to enhance security is to deploy traffic sniffers that can provide auditable communications logs. Unfortunately, current sniffers can only target one connection at a time, requiring that a separate sniffer be assigned to each device of interest. This becomes impractical for a wireless sensor network, which often employs a multitude of sensors simultaneously. Additionally, some open-source sniffers lack the functionality to synchronize with active connections, causing a drastic drop in the probability of capture over the length of a connection. This paper extends sniffer capabilities to audit and defend Bluetooth Low Energy devices used in the critical infrastructure. It introduces Bluetooth Low Energy Multi (BLE-Multi), a firmware solution built on the Ubertooth One platform, that can reliably sniff multiple connections simultaneously. The work has four main contributions: (i) improved connection synchronization compared with other open-source sniffer platforms; (ii) a novel multi-connection tracking scheme and implementation; (iii) an evaluation of commercially-available and open-source sniffers; and (iv) a baseline evaluation of frame capture rates when sniffing multiple connections. 2. Background

AC

CE

This section discusses the current state of Bluetooth Low Energy security and motivates the need for auditing captured traffic. It also presents the advantages and limitations of available Bluetooth Low Energy sniffers. 2.1. Bluetooth Low Energy security The Bluetooth Special Interest Group introduced Bluetooth Low Energy, also known as Bluetooth Smart, in Bluetooth Core Specification Version 4.0 [2] as a low-energy and low-data rate wireless communications protocol. Although Bluetooth Low Energy is lumped under the Bluetooth name, it is a different protocol from Bluetooth Basic Rate/Enhanced Data Rate 3

ACCEPTED MANUSCRIPT

AC

CE

PT

ED

M

AN US

CR IP T

(BR/EDR), otherwise known as Bluetooth Classic [13]. While Bluetooth Classic can be used for high data-rate applications (e.g., audio streaming and data sharing), Bluetooth Low Energy is designed to transmit stateful information, such as the temperature of a room or whether a lock is open. These transmissions, which require short bursts at a much lower data rate, are particularly useful for critical infrastructure and Internet of Things (IoT) applications. The Bluetooth Low Energy specification [3] presents low-level security mechanisms for enhancing Bluetooth Low Energy security. It defines procedures to enable device-specific authentication, data encryption and redundancy checks for data integrity at the link layer. The main procedure, called binding or pairing, outputs a set of 128-bit symmetric keys used for encryption and authentication. In 2013, Ryan [22] published a security evaluation that highlighted flaws in the pairing procedure that left it vulnerable to an observant attacker. Specifically, an attacker who can capture a pairing exchange in its entirety can crack the 128-bit symmetric encryption key and fully decrypt Bluetooth Low Energy communications. The Bluetooth Special Interest Group has since enhanced the security of key exchange by adopting the Elliptic Curve Diffie-Hellman (ECDH) algorithm in Bluetooth Version 4.2 [3]. In practice, few devices implement link layer security, instead relying on custom higher-level security or no security at all [12]. Link layer security mechanisms are optional due to their increased energy consumption – increased security comes with increased energy costs [13]. For this reason, the Bluetooth Special Interest Group places the burden on developers and vendors to make design decisions about security mechanisms. Whether developers are motivated by energy consumption or other design decisions or pushing products to market quickly, the end result is that most devices lack appropriate security mechanisms. In 2016 alone, the lack of link layer security contributed to the development of multiple Bluetooth Low Energy attacks, exploitation frameworks and reconnaissance tools. Two teams developed man-in-the-middle frameworks that can be used against vulnerable targets [4, 16]. Both frameworks prey on devices that lack link layer authentication and encryption. A security evaluation highlighted a critical vulnerability in an over-the-air (OTA) firmware update that left devices vulnerable to attackers [12]. Other researchers were able to open several commercially-available Bluetooth Low Energy locks from up to a quarter mile away [21]. Two other teams have de4

ACCEPTED MANUSCRIPT

(b) Bluefruit LE.

(c) Ubertooth One.

CR IP T

(a) TI CC2540.

Figure 1: Commercially-available Bluetooth Low Energy sniffers.

CE

PT

ED

M

AN US

veloped commercially-available Bluetooth Low Energy reconnaissance tools that exfiltrate private information and track the approximate locations of nearby Bluetooth Low Energy devices in real time [21, 24]. In the same year, research focused on Bluetooth Low Energy privacy violations drove the development of BLE-Guardian, an active Bluetooth Low Energy privacy protection tool [8]. BLE-Guardian offers a front end for authentication and a novel process for restricting connections to authenticated devices. Also, it uses jamming to hide advertisements by protected BLE devices, preventing unauthorized access. While BLE-Guardian focuses on protecting unconnected devices, BLE-Multi monitors devices after connections are initiated. In the future, BLE-Guardian and BLE-Multi could be combined to create a more comprehensive security solution for protecting Bluetooth Low Energy devices. Until vendors implement stronger link layer security, administrators should monitor Bluetooth Low Energy devices under their authority, especially devices that have the potential to impact business operations. The research described in this paper contributes to this goal by creating a flexible traffic capture solution that generates auditable communications logs of Bluetooth Low Energy connections, which can be used to implement automated intrusion detection and prevention functionality.

AC

2.2. Bluetooth Low Energy sniffers Figure 1 shows three commonly-used Bluetooth Low Energy sniffers. The TI CC2540 and Bluefruit LE sniffers are pre-loaded with proprietary firmware and are designed to assist with application debugging. Nordic Semiconductor provides sniffer firmware that can be installed on any Bluetooth Low Energy radio chip in the nRF51 family to include the nRF51 Development Kit and the nRF51822 chip used in the Adafruit Bluefruit LE platform. Ubertooth One can be flashed with open-source sniffer firmware from its online code repository (see [10]) or with custom firmware for specialized applications. 5

ACCEPTED MANUSCRIPT

Table 1: Comparison of commercially-available sniffers and BLE-Multi.

Platform

Firmware

Connections

TI CC2540 Bluefruit LE Ubertooth One

Windows Windows/Linux Linux

Proprietary Proprietary Open source

One, synchronized One, synchronized One, unsynchronized

BLE-Multi

Linux

Open source

Multiple, synchronized

CR IP T

Sniffer

CE

PT

ED

M

AN US

Table 1 highlights the key differences and limitations of the three sniffers compared with BLE-Multi. While the capabilities vary across sniffers, the one limitation shared by all currently-available sniffers is their ability to monitor only a single active Bluetooth Low Energy connection. This restriction make sense when using a sniffer as a traffic analysis tool for debugging or troubleshooting because it maximizes the probability of capturing every frame in the conversation. However, when using a sniffer in a risk management framework or for a security appliance, it is acceptable to sacrifice frame capture in exchange for other more important capabilities. Another limitation affecting Ubertooth One is that its firmware does not employ a mechanism for maintaining synchronization with an active connection. Connection synchronization is necessary because clocks on different devices can drift from each other. Because Bluetooth Low Energy communications require interactions on specific frequencies at specific times, the Bluetooth Low Energy specification provides a procedure to account for clock drift. Unfortunately, the procedure relies on frame directionality, which is not discernible through frame inspection and is, therefore, difficult to extract by a sniffer. BLE-Multi removes these two limitations by incorporating mechanisms for capturing and synchronizing with multiple simultaneous connections.

AC

3. Bluetooth Low Energy connections The structure of a Bluetooth Low Energy connection is significant to the sniffing mechanisms presented in this work. A connection occurs between two parties: (i) one master; and (ii) one slave. Each Bluetooth Low Energy connection comprises a series of connection events with varying lengths. The master communicates parameters to dictate the intervals and frequencies of 6

CR IP T

ACCEPTED MANUSCRIPT

AN US

Figure 2: Overview of a Bluetooth Low Energy connection.

M

Figure 3: Single Bluetooth Low Energy connection showing the effects of connection parameters.

PT

ED

the connection events. The slave generally has no control over these parameters, but can choose to leave the connection at any time. Although the Bluetooth Low Energy specification allows one master to link with multiple slaves and one slave to link with multiple masters, each link is treated as a separate connection with its own parameters. Figure 2 presents a schematic diagram of the Bluetooth Low Energy connection process. The process involves the following steps:

AC

CE

1. Slave advertises presence: Slaves broadcast frames on one of three advertisement channels. The advertisements contain information about connectability and the services provided by the slaves. A master observes the advertisements to determine which slaves are available for connection. The master can only connect to a slave that advertises its presence. 2. Master sends connection request: To begin a connection, the master sends a connection request (CR) containing critical connection parameters within 150 µs after the end of an advertisement. The most important parameters are the connection interval, window size, window offset, 7

ACCEPTED MANUSCRIPT

AC

CE

PT

ED

M

AN US

CR IP T

hop interval, channel map and master sleep clock accuracy (SCA). The window size and window offset determine the time of the first connection event, and the connection interval determines the timing of every connection event after the first. The hop interval and channel map describe the frequencies on which the master and slave communicate. The master sleep clock accuracy is key to the synchronization mechanism. Figure 3 shows the effects of the connection parameters. Note that the start time and frequency of each connection event are essentially predetermined by the connection parameters exchanged at the start of the connection. This is generally a valid assumption with two exceptions. First, the master and slave may have different expectations about when a given connection event should start, depending on how far the clocks (master and slave) have drifted from each other; Bluetooth Low Energy handles this phenomenon using a synchronization mechanism that relies on the timing of the first frame in each connection event. Second, the master may choose to change the connection parameters at any point in the conversation; when the master makes a change, it selects a time in the future at which the change will take place and both parties adjust the schedule of connection events accordingly. 3. Hop: Bluetooth Low Energy devices operate in the 2.4 GHz industrial, scientific and medical (ISM) frequency band. The Bluetooth Low Energy specification divides the band into 40 2 MHz channels. It reserves three channels for advertisements and uses the remaining channels for data transmission in active connections. During a hop, the master and slave tune their radios to a new frequency, as defined by the channel map, hop increment and hopping algorithm. Note that two arbitrary Bluetooth Low Energy connections will likely talk on two different channels at any point in time. This is the primary limitation to multi-connection sniffing because a single radio cannot listen to more than one channel at a time. 4. Master sends anchor: At the beginning of the connection event, the master sends a data frame (empty or otherwise) on the appropriate frequency. This first frame, which is called an anchor, is critical to connection synchronization. 5. Slave responds: The slave is not required to respond to the anchor frame. It can remain inactive for a predetermined number of connection events. If the slave responds, the master and slave begin to exchange 8

ACCEPTED MANUSCRIPT

ED

M

AN US

CR IP T

frames. 6. Master and slave alternate frames: After the slave responds to the anchor, both sides alternate sending frames until the connection event ends. Each frame contains a sequence number and the next expected sequence number, which serves as a receipt acknowledgement for the previous frame. The length of a connection event is determined by how much data is available for transmission; this depends on the higher layers of the Bluetooth Low Energy stack. The connection event ends if: (i) both parties have no more data or acknowledgments to transmit; (ii) neither party sends a frame within 150 µs; or (iii) the connection ends. Many connection events have an empty anchor frame from the master followed by an empty acknowledgement from the slave. Bluetooth Low Energy requires frame transmission (even of empty frames) to periodically synchronize connections and ensure that both parties are still engaged in communications. The adapted synchronization mechanism employed by BLE-Multi relies on the fact that many connection events consist of only two empty frames. 7. Connection event ends: The end of a connection event does not necessarily imply the end of a connection. If the connection has not ended, the master and slave remain inactive until the master sends the anchor of the next connection event. 8. Connection ends: If either party sends an LL TERMINATE IND packet, the connection ends and the slave starts advertising its presence again.

CE

PT

BLE-Multi leverages the structure of Bluetooth Low Energy connections by looking for consecutive empty frames in short connection events to extract anchors and by opportunistically employing time gaps between connection events to listen to other connections.

AC

4. Design considerations This section discusses the assumptions and considerations that have led to the design of BLE-Multi as an extension of the Ubertooth One firmware. 4.1. General considerations The goal of a sniffer is to capture every frame sent between a master and slave. Since the master controls the link layer parameters that control 9

ACCEPTED MANUSCRIPT

AC

CE

PT

ED

M

AN US

CR IP T

the connection, in order to follow a connection, a sniffer can simply act like the slave, capturing and interpreting link layer control messages from the master. As a relayer of data, a sniffer is not required to process data intended for higher layers in the Bluetooth Low Energy stack; instead, it can indiscriminately forward data to the host or end user. A unique situation arises with the encryption procedure. When a master or slave enables encryption, both sides use a symmetric 128-bit key and AES128 block cipher to perform encryption at the link layer. Traffic captured by a sniffer, including link control messages, would be incomprehensible to the sniffer and end user. This work focuses on protecting unsecured devices and, therefore, assumes that neither the master nor the slave enable encryption. Another key assumption is that a sniffer is a passive third-party participant in a conversation. This assumption implies that a sniffer cannot transmit packets to alter a conversation in any way. For example, it cannot request packet re-transmission, negotiate more convenient connection parameters or otherwise actively interfere with a connection. An additional implication of its third-party status is that a sniffer cannot easily determine the directionality of an observed frame because a frame does not encode sender or receiver information. Such information is obvious in a two-party conversation and is, therefore, omitted (i.e., if the slave receives a frame, it must have come from the master). A passive third-party listener cannot make the same inference. This creates problems for the Bluetooth Low Energy synchronization mechanism because it relies on the timing of anchor frames sent by the master. Section 5.1 addresses this issue by proposing a synchronization mechanism that relies on consecutive empty frames. Note that this work does not seek to overcome the physical limitations imposed by radio frequency (RF) communications. It does not address radio factors that affect how well it can decode bit sequences from RF energy, nor does it address the effects of interference and noise on the crowded 2.4 GHz ISM band. Instead, it abstracts factors such as signal to noise ratio and bit errors as an overall degradation in frame capture success. 4.2. Ubertooth One considerations This research has developed BLE-Multi as an extension to the current Ubertooth One firmware for two reasons. First, Ubertooth One is a flexible open-source hardware platform that lends itself to rapid proof-of-concept development. Second, Ubertooth One is widely used by the security community because it can capture several communications protocols. Thus, an 10

ACCEPTED MANUSCRIPT

CE

PT

ED

M

AN US

CR IP T

extension of the Ubertooth One platform would be of interest to the security community. The current firmware, named bluetooth-rxtx, is capable of sniffing Bluetooth Classic and Bluetooth Low Energy connections [10]. Its main mode of operation relies on clock interrupts to drive channel hops and radio retuning. Although the available clock resolution for timestamps is 100 ns, clock interrupts run 3,125 times slower at a frequency of 3,200 Hz. While it is possible to increase the frequency by writing to registers on the on-board CC2400 radio, any change to the interrupt frequency would impact all the other functionality of bluetooth-rxtx. Hence, BLE-Multi is restricted to a clock interrupt precision of 312,500 ns. To account for the relatively low precision, BLE-Multi makes conservative approximations when computing its deadlines and timers. For example, when calculating the timer associated with a connection interval, BLE-Multi rounds down to the nearest multiple of 312,500 ns, ensuring that the radio performs a hop before the connection interval actually begins. In contrast, when computing the timer associated with the length of a connection event, BLE-Multi rounds up, conservatively extending the amount of time that the radio spends on the channel. A final implementation consideration regarding Ubertooth One is that a frame timestamp is taken after a frame is completely received, but many Bluetooth Low Energy computations require knowledge about the timing of the first bit in the frame. Adding to the problem is the time taken for the radio to capture the frame and forward it to the processor. Since there is currently no built-in method to know when a frame is first received, BLE-Multi subtracts a constant from every frame timestamp. This constant encapsulates the frame transmission delay and any other processing delays. In fact, the constant was experimentally tuned throughout the firmware development process. 5. Following a single connection

AC

In theory, a sniffer only needs to act like a slave in order to follow an active connection. However, in practice, a sniffer does not have the benefit of participating actively in a connection. Although this limitation removes the responsibilities of a sniffer with regard to link layer control, it limits the ability of the sniffer to synchronize to a connection. This section discusses how BLE-Multi handles connection synchronization.

11

ACCEPTED MANUSCRIPT

AN US

CR IP T

5.1. Synchronization Clock synchronization is essential to Bluetooth Low Energy communications because the protocol employs frequency hopping triggered on time intervals. Poor synchronization can have adverse effects on sniffing. To illustrate the problem, assume that the master has a clock drift of 250 parts per million (ppm), typical for a standard Cypress CYW20702 Bluetooth Low Energy transceiver used in many commercial dongles [6]. The 16 MHz oscillator in Ubertooth One has a clock drift of 20 ppm [1]. In the worst case, after only 45 seconds, the clocks on the Ubertooth One and the master would have drifted a full 12.15 ms from each other. Since a normal frame is transmitted in less than 150 µs, the Ubertooth One sniffer would have potentially missed some of (or all) the frames across multiple connection events. The remainder of this section describes the built-in Bluetooth Low Energy synchronization mechanism and the adaptations made in BLE-Multi.

ED

M

Synchronization in Bluetooth Low Energy. The Bluetooth Low Energy specification addresses the issue of clock drift via a synchronization mechanism based on the timing of messages from the master. Using the connection request, the master informs a slave of its sleep clock accuracy or clock drift. After the slave receives an anchor (i.e., first packet sent by master), it predicts when the next anchor will arrive using the connection interval:

PT

nextAnchor = lastAnchor + connectionInterval

AC

CE

Because the master and slave clocks can drift apart, the slave calculates a window of time during which it should listen for the next anchor. Since the slave knows its own sleep clock accuracy (SCAS ) and the sleep clock accuracy of the master (SCAM ), it can compute the window of time for the next anchor based on the maximum amount of time that the clocks could have drifted. The Bluetooth Low Energy specification defines this as window widening [3]:

windowW idening =

(SCAM + SCAS ) × connectionInterval 1, 000, 000

12

CR IP T

ACCEPTED MANUSCRIPT

Figure 4: Relationship between anchors, connection parameters and BLE-Multi timers.

AN US

As shown in Figure 4, the slave listens for the next anchor in the time interval: t ∈ [nextAnchor − windowW idening, nextAnchor + windowW idening]

M

Every time a new anchor arrives, the slave recalculates nextAnchor, shifting the listening window forward in time. Note that the slave is responsible for maintaining synchronization. By extension, it is the responsibility of the sniffer to maintain synchronization with the master. However, this presents unique challenges for third-party listeners.

AC

CE

PT

ED

Synchronization in sniffers. Since the slave synchronizes with the master, the sniffer does not need to know the sleep clock accuracy SCAS of the actual slave; it simply needs to use its own sleep clock accuracy SCAU bertooth . However, as discussed above, anchors are not marked in any way. The sniffer does not know and cannot infer whether a frame came from the master or the slave based on frame content. Clearly, this makes it problematic to determine when to listen for future anchors. One approach is to assume that the first frame received by the sniffer is an anchor. However, if this frame is not actually an anchor, the sniffer incorrectly approximates nextAnchor, causing problems with subsequent connection events. Another approach is to follow the frame sequence numbers and make guesses about missed and dropped frames, but this approach is impractical as far as this research is concerned. BLE-Multi could deliberately choose not to listen to a connection event in lieu of another connection, causing the sniffer to lose track of sequence numbers. 13

ACCEPTED MANUSCRIPT

CR IP T

While it may not be possible to determine an anchor for every connection event, a certain sequence of frames guarantees the presence of an anchor. If two frames that are received consecutively (within 150 µs of each other) contain no data and have the more data (MD) bit set to zero, then the first frame is an anchor. This property is formalized as Claim 1.

Claim 1: If two consecutive frames f1 and f2 have no data and M D = 0, then f1 is an anchor. Proof: Suppose that f1 is not an anchor. By definition, at least one frame was transmitted before f1 . Let the frame that was transmitted immediately before f1 be f0 . M Df0 is either 0 or 1.

M

AN US

• Case (i): M Df0 = 0. Because M Df0 = 0, the sender of f0 does not send any more frames containing data. Since f1 has no data and M Df1 = 0, both parties interpret f1 as the end of the connection event according to the Bluetooth Low Energy specification. Thus, neither side sends another frame in the current connection event. However, this contradicts the assumption that f2 is sent. Thus, it follows that Case (i) cannot occur.

PT

ED

• Case (ii): M Df0 = 1. Because M Df0 = 1, the sender of f0 has more data to transmit the next time it sends a frame. Since the master and slave alternate frame transmission, the data is transmitted in the slot for f2 . However, this contradicts the assumption that f2 has no data. Thus, it follows that Case (ii) cannot occur.

AC

CE

Since neither Case (i) nor Case (ii) can occur, f0 could not have been transmitted. Therefore, f1 must be the first frame in the communication and, by definition, an anchor.  Under this assumption, BLE-Multi cannot extract an anchor from every connection event like a slave. However, the sequence of frames described above occurs frequently when the link layer awaits data from higher layers. It is, therefore, feasible to maintain connection synchronization. When the sniffer observes the sequence, it updates lastAnchor and nextAnchor and computes when the next connection event will take place. 14

ACCEPTED MANUSCRIPT

Table 2: Critical advertisement channel messages and their effects on connections.

Effect on Connection

ADV IND

Advertiser is connectable Action: Capture CONNECT REQ

ADV DIRECT IND

Advertiser is connectable Action: Capture CONNECT REQ

CONNECT REQ

Sender requests a connection with the advertiser Action: Extract the connection parameters and actively follow the connection

AN US

CR IP T

Message Type

M

In practice, BLE-Multi achieves synchronization using two timers that decrement with every clock interrupt: (i) intervalT imer; and (ii) connEventT imer (Figure 4). When intervalT imer expires, BLE-Multi triggers the Bluetooth Low Energy radio to hop to and listen on the next channel in the hopping scheme. At this point, the sniffer recalculates nextAnchor and updates intervalT imer as: intervalT imer = nextAnchor − windowW idening − currentT ime

ED

and it enables connEventT imer, which is set to: connEventT imer = 2 × windowW idening

CE

PT

The end of connEventT imer signifies the latest time that the next anchor could arrive. If, at any point, BLE-Multi receives a frame before connEventT imer expires, then it assigns 150 µs to connEventT imer, which is the maximum amount of time without transmission after which a connection event must end.

AC

5.2. Link layer control When a sniffer acts as a slave, it must react appropriately to link layer control frames; specifically, the frames that dictate or impact connection parameters. Tables 2 and 3 list the critical commands sent on the advertisement and data channels. Note that a sniffer only needs to take action on three of the seven types of packets sent on advertisement channels and three of the 22 types of packets 15

ACCEPTED MANUSCRIPT

Table 3: Critical data channel control messages and their effects on connections.

Effect on Connection

LL CONNECTION UPDATE REQ

Master dictates the changes to the parameters Action: Apply the new connection parameters

LL CHANNEL MAP REQ

Master dictates the changes to the channel map Action: Apply the new channel map

LL TERMINATE IND

Sender terminates the connection Action: Stop following the connection

M

AN US

CR IP T

Message Type

ED

Figure 5: BLE-Multi connection event scheduler.

CE

PT

sent on data channels. These six types of packets are critical because they signal changes in the underlying connections. To clarify, this does not mean that the sniffer does not capture other types of packets – it does, but it does not take any action. 6. Following multiple connections

AC

A sniffer can take advantage of the characteristics of Bluetooth Low Energy connections to opportunistically follow multiple conversations. This section shows how BLE-Multi accomplishes this task. 6.1. Procedure Figure 3 in Section 3 shows the empty space after a connection event that can be used to listen to other connections. By simultaneously tracking the 16

ACCEPTED MANUSCRIPT

Algorithm 1 : Schedule. 1: Procedure Schedule(activeLinks) : nextLink

CR IP T

AN US

ED

12: 13: 14: 15: 16: 17: 18:

M

2: 3: 4: 5: 6: 7: 8: 9: 10: 11:

Input: Current set of active links being tracked (activeLinks) Output: Next link to capture (nextLink) begin minT imer ← ∞ minLink ← NULL for link ∈ activeLinks do . Find the link with the minimum timer if link.intervalT imer < minT imer then minLink ← link minT ime ← link.intervalT imer end if end for if minT imer ≥ M IN ADV T IM E then . Listen for advertisements if there is enough time nextLink ← advertisementLink return nextLink else nextLink ← minLink return nextLink end if end

AC

CE

PT

states of multiple active connections, BLE-Multi can make decisions about which connection to capture after a connection event ends. Figure 5 shows how the empty spaces between connection events can be used more efficiently by a sniffer when capturing three simultaneous connections. The connection events on the left-hand side of the scheduler have already been captured while the connection events on the right-hand side are expected to occur in the future. At the end of each connection event, Algorithm 1 is used to determine the next link to capture based on the time remaining before the next connection event. BLE-Multi also employs an advertisementLink, which it treats as a default link. If there are no active links or there is still enough time before the next connection event, then the scheduler selects the advertisementLink, which is always configured to track an advertisement channel. This is how the sniffer adds new connections to the set of active links. Currently, the scheduler selects the link with the most imminent connec17

ACCEPTED MANUSCRIPT

CR IP T

tion event (i.e., link with the minimum intervalT imer). However, the sniffer is not limited in the selection algorithm it can use. For example, another implementation may select the link that has been active the longest (oldest first) or the link that has been captured least recently (longest since last capture). Each resulting algorithm would have unique implications with regard to the data capture capabilities at each link.

AC

CE

PT

ED

M

AN US

6.2. Limitations To be sure, the physical limitation of the Bluetooth Low Energy radio still exists (i.e., the sniffer is only able to listen to one channel at a time). However, connection events do not normally use the entire connection intervals, enabling BLE-Multi to timeshare across multiple connections. This differs from the approach used by Ossman and Spill [19], which conducts wideband sniffing of Bluetooth Classic communications by capturing multichannel chunks of the 2.4 GHz spectrum and extracting the Bluetooth conversation via post-processing. This physical limitation of sniffing one channel at a time manifests itself when sniffing multiple connections with multiple masters. If active connections are initiated by separate masters, then connection events may overlap in separate connections. BLE-Multi is forced to choose one connection over the other, and the overall frame capture rate may drop. In contrast, connections that share a master are optimal for BLE-Multi because the master automatically deconflicts connection events. In this case, events do not overlap and BLE-Multi can listen to a larger number of events. However, even if BLE-Multi encounters multiple connections with multiple masters, connection events often consist of empty frames (no data). This is the key concept that enables BLE-Multi to synchronize with active connections. Hence, missed connection events do not necessarily imply missed data. Finally, a master may change the connection parameters in the middle of a conversation. When listening to multiple active connections, BLE-Multi has a greater probability of missing a link control frame. This could cause the sniffer to fall out of synchronization with the corresponding link. 7. Experimental evaluation Sniffer evaluation is inherently difficult because there is no mechanism to extract the number of link layer frames transmitted or received by a 18

AN US

CR IP T

ACCEPTED MANUSCRIPT

Figure 6: Generic experimental setup (numbered bubbles are active links for Experiments 1, 2 and 3).

PT

ED

M

transceiver in a Bluetooth Low Energy dongle. Ideally, an evaluation would compare the number of frames captured by the sniffer with the number of frames actually transmitted. Unfortunately, the dongle hides low-level communications from the host, including empty frames and link control frames, disqualifying the most obvious metric of percentage of frames captured. Thus, the experiments described in this section target the reception of usable and actionable data embodied by a single command sent from the master to a slave at a random time after the connection starts.

AC

CE

7.1. Experimental design The three experiments discussed in this section used the same experimental setup, procedure and data analysis techniques: • Experimental setup: Figure 6 provides an overview of the experimental setup. A laptop with a 2.4 GHz Intel Core i7 processor, 8 GB RAM and Kali Rolling 2016.1 operating system controlled the timing and data collection for each experiment. The sniffers under test were connected to a powered USB 2.0 hub that was connected directly to the laptop. Two Bluetooth Low Energy dongles with CYW20702 transceivers were 19

ACCEPTED MANUSCRIPT

CR IP T

connected to an additional powered USB 2.0 hub, which was also connected to the control laptop. The dongles were placed 30 cm away from an Onset MX1101 temperature/humidity sensor and an August Smart Lock. The two targets represented different classes of critical infrastructure applications: (i) environmental sensing; and (ii) building security. Additionally, these targets did not implement short timeouts on active connections, meaning that each trial could run for more than 45 seconds without receiving an automatic disconnect from the target.

AN US

Figure 6 also illustrates the active links for each of the three experiments. Experiment 1 only established the link between a single dongle and a single target. Experiment 2 connected a single dongle to two targets. Experiment 3 used two separate dongles to connect to two targets (one each).

PT

ED

M

• Trials: Trials were aggregated to extract the likelihood of a frame being captured at increasing Bluetooth Low Energy connection times. A Python script controlled the experiments, where each trial involved the following steps: 1. Establish the required connections (shown in Figure 6) in pseudorandom order using random.randint() written in Python. 2. Wait for a delay of 0, 15, 30 or 45 seconds selected randomly by random.randint() written in Python. 3. Send a single target frame with byte sequence 0x010108010855 to each slave in the order in which the connections were established. 4. Disconnect from each slave in the order in which the connections were established.

CE

Experiment 1 involved 500 × 4 trials while Experiments 2 and 3 involved 150 × 4 trials due to time limitations. A trial was deemed to be successful if the sniffer captured the target frame with the specified byte sequence.

AC

• Success proportion computation: Trials were aggregated to compute the success proportion for each time delay. The number of trials n in an experiment represented a single population sample of length n. The sample proportion pbi was computed using the number of successful captures si at a time delay i ∈ {0, 15, 30, 45} and n: si pbi = n 20

ACCEPTED MANUSCRIPT

Table 4: Raw results for Experiment 1 (one master to one slave).

Bluefruit LE

i

Successes

p ˆi

95% CI

Successes

0 15 30 45

499/500 498/500 500/500 497/500

0.998 0.996 1.000 0.994

±0.004 ±0.006 – ±0.007

494/500 498/500 498/500 496/500

Ubertooth One

p ˆi

95% CI

CR IP T

TI CC2540

±0.010 ±0.006 ±0.006 ±0.008

0.988 0.996 0.996 0.992

BLE-Multi

Successes

p ˆi

95% CI

Successes

0 15 30 45

469/500 409/500 362/500 314/500

0.938 0.818 0.724 0.628

±0.021 ±0.034 ±0.039 ±0.042

420/500 412/500 411/500 430/500

p ˆi

95% CI

0.840 0.824 0.822 0.860

±0.032 ±0.033 ±0.034 ±0.030

AN US

i

ED

M

The resulting pˆi was used as an unbiased estimator of the proportion in order to compute a 95% confidence interval: ! r pˆi (1 − pˆi ) pbi ± 1.96 n

AC

CE

PT

7.2. Experiment 1: One master to one slave This experiment compared the proportions of trials with successful frame captures for the BLE-Multi, Ubertooth One, TI CC2540 and Bluefruit LE sniffers over the lengths of connections. Table 4 and Figure 7 show the results obtained for Experiment 1. Note that a 95% confidence interval (CI) was computed for the success proportion. The TI 2540 and Bluefruit LE performed the best with regard to the frame capture rate and synchronization. Both are closed-source commercial sniffers that use hardware specifically designed for Bluetooth Low Energy communications. In contrast, the open-source Ubertooth One and, by extension, BLE-Multi tune an older generic 2.4 GHz radio not specifically designed for Bluetooth Low Energy. The difference in hardware could account for the 21

AN US

CR IP T

ACCEPTED MANUSCRIPT

Figure 7: Frame capture success of a single connection over time.

AC

CE

PT

ED

M

performance gap between the commercial and open-source sniffers. However, this work employed Ubertooth One because of its flexibility for rapid proof-of-concept development and its impact to the security community. The decreasing trend in the success proportion of Ubertooth One is likely due to the lack of a connection synchronization mechanism. Conversely, the non-decreasing trend in the BLE-Multi data suggests that the adapted synchronization mechanism achieves synchronization over the length of a connection. An apparent side effect of BLE-Multi is that, while it achieves overall synchronization and stability, its capture success is 5 to 15% lower than Ubertooth One for connections lasting less than 15 seconds. This could be due to the active use of advertisementLink, where the sniffer moves away from an active connection to listen to an advertisement channel. Or, it could stem from an expanded processor payload as a result of the added logic. There may be ways to optimize BLE-Multi to surpass Ubertooth One, but this research focused on developing the proof-of-concept mechanisms to perform synchronization and capture multiple connections. 7.3. Experiment 2: One master to multiple slaves This experiment tested the effectiveness of BLE-Multi on two simultaneous connections between a single master and multiple slaves. Leveraging

22

ACCEPTED MANUSCRIPT

Table 5: Raw results for Experiment 2 (one master to two slaves).

August Smart Lock

i

Successes

p ˆi

95% CI

Successes

0 15 30 45

129/150 133/150 130/150 127/150

0.860 0.887 0.867 0.847

±0.056 ±0.051 ±0.054 ±0.058

122/150 128/150 122/150 120/150

p ˆi

95% CI

CR IP T

MX1101 Sensor

0.813 0.853 0.813 0.800

±0.062 ±0.057 ±0.062 ±0.064

MX1101 Sensor

AN US

Table 6: Raw results for Experiment 3 (two masters to two slaves, one each).

August Smart Lock

Successes

p ˆi

95% CI

Successes

p ˆi

95% CI

0 15 30 45

130/150 123/150 135/150 128/150

0.867 0.820 0.900 0.853

±0.054 ±0.061 ±0.048 ±0.057

126/150 128/150 127/150 134/150

0.840 0.853 0.847 0.893

±0.059 ±0.057 ±0.058 ±0.049

ED

M

i

AC

CE

PT

the generic setup, the experiment employed a single sniffer under test with BLE-Multi, one Bluetooth Low Energy dongle and the two targets. A single master connected to two slaves automatically deconflicted both connections by ensuring no overlap between connection events. In other words, the two connections were optimal for simultaneous capture because BLE-Multi never had to miss one connection event in favor of another. Table 5 shows the raw experimental results while Figure 8 illustrates the same results and compares them with the proportion of successful trials of Ubertooth One in Experiment 1. The stable BLE-Multi data trends for the MX1101 and August Smart Lock show that BLE-Multi was able to capture and maintain synchronization with both connections simultaneously. Notably, in the case of long connections, BLE-Multi on multiple connections performed better than Ubertooth One on a single connection.

23

AN US

CR IP T

ACCEPTED MANUSCRIPT

Figure 8: Frame capture success of two connections with one master (95% CI for proportion).

AC

CE

PT

ED

M

7.4. Experiment 3: Multiple masters to multiple slaves This experiment tested the effectiveness of BLE-Multi on two simultaneous connections between two masters and two slaves (one slave per master). Leveraging the generic setup, the experiment employed a single sniffer under test with BLE-Multi, two Bluetooth Low Energy dongles and the two targets. Table 6 and Figure 9 and show the results of Experiment 3. The results for Ubertooth One in Experiment 1 are added for reference. The use of two master-slave pairs increased the likelihood of overlapping connection events. In such a situation, BLE-Multi could be forced to deliberately ignore a connection event and potentially miss data. However, the results show that, as in Experiment 2, BLE-Multi was able to capture data and maintain synchronization with both connections simultaneously. Under the conditions in Experiment 3, overlapping events did not have a statistically significant effect on BLE-Multi capabilities. One contributing factor is that the connections observed in Experiment 3 were relatively quiet; in other words, most connection events consisted only of two empty frames. This provided the sniffer with more time between connection events and consequently, more time to listen to other connections. Following more than two connections or more active connections would likely yield a lower proportion of successful trials per connection. 24

AN US

CR IP T

ACCEPTED MANUSCRIPT

Figure 9: Frame capture success of two connections with two masters (95% CI for proportion).

M

8. Analysis

AC

CE

PT

ED

The results of Experiments 2 and 3 support the claim that BLE-Multi can follow and capture more than one simultaneous Bluetooth Low Energy connections. Furthermore, the non-decreasing trends in all the BLE-Multi data support the claim that the synchronization mechanism introduced in this work, which relies on frequent transmissions of empty frames, is a practical solution for long-lived connections. Note that the two proprietary sniffers were also able to synchronize to long-lived connections. However, the advantage that BLE-Multi holds over the proprietary sniffers is that it can capture more than one connection at a time. Because of its synchronization mechanism, BLE-Multi (on multiple connections) can capture frames better than Ubertooth One (on a single connection) for connections lasting longer than fifteen seconds. However, on connections that last less than fifteen seconds, BLE-Multi is 5 to 15% less likely than Ubertooth One to capture frames. Since BLE-Multi is an extension of the Ubertooth One firmware, the drop in trial success is likely due to the added workload required to capture multiple connections. Nevertheless, BLE-Multi was able to capture the target frames more than 70% of the time in all the evaluated cases. 25

ACCEPTED MANUSCRIPT

AN US

CR IP T

Admittedly, while these proportions of successful frame captures may be acceptable for applications that seek to bolster security, they may not be enough for applications that require greater scrutiny of traffic. Ideally, each of the simultaneous Bluetooth Low Energy connections would be captured by one commercial sniffer, maximizing the likelihood of frame capture. Unfortunately, such a system of sniffers may be difficult to scope, design and deploy because the number of active connections in an environment would not be known in advance. Cost-benefit analyses should be performed for specific applications to determine whether BLE-Multi is an acceptable traffic capture solution. Ultimately, BLE-Multi provides security professionals with the flexibility necessary to audit evolving Bluetooth Low Energy environments by capturing more than one active conversations at a time while simultaneously listening for new connections. 9. Future research

AC

CE

PT

ED

M

This section describes avenues for future research involving Bluetooth Low Energy and wireless sensor network security. BLE-Multi uses several constant parameters that affect the timing calculations. These parameters can be experimentally tuned to improve sniffer reliability. Additionally, the period between clock interrupts can be shortened to increase the precision of intervalT imer and connEventT imer. A more precise clock would enable tighter windows around connection events and allow more time for capturing other links. Comparisons between the tuned BLE-Multi sniffer and commercial sniffers, specifically related to advertisement and connection request capture, would be useful. The Bluetooth Low Energy advertisement mechanism enables a device to use between one and three advertisement channels. The device sends an advertisement on each advertisement channel in order of increasing frequency and a master is allowed up to 150 µs to respond. A tuned, more precise sniffer should be able to follow an advertising device as it moves through the advertisement channels, increasing the probability of capturing a connection request and, consequently, the probability of following a connection. Another area of capability expansion deals with the selection algorithms employed by the scheduler. The new algorithms may prioritize links that have been active the longest (oldest first) while others may select links that have been waiting the longest to perform a capture (longest since last capture).

26

ACCEPTED MANUSCRIPT

AN US

CR IP T

The various algorithms would have different implications on the performance of BLE-Multi. Mobile masters and slaves pose a challenge to traffic capture tools because the relative positions and orientations between the target transceivers and sniffer antenna constantly change. Given the increased use of Bluetooth Low Energy by mobile devices such as smartphones and tablets, future research should analyze the impact of mobile attackers and mobile targets on BLEMulti. Intrusion detection systems can be challenging to deploy in wireless sensor networks because the sensors require significant power draws [23]. BLE-Multi provides the traffic visibility necessary to perform intrusion detection without drawing additional power from a sensor network. Specifically, the following attacks may be detected by BLE-Multi sniffers: • Man-in-the-middle attacks: If an intrusion detection system identifies that BLE-Multi is following two distinct active connections with the same “target” address, it could be a sign that an attacker may be positioning himself between the real target device and the victim.

ED

M

• Password attacks: An intrusion detection may correlate multiple connection events associated with the same connection to determine if an attacker is attempting a dictionary attack or a brute force password attack.

CE

PT

• Firmware attacks: An intrusion detection system can perform filtering based on data higher in the Bluetooth Low Energy protocol stack. High-level commands to firmware update services, such as those employed by Gutierrez del Arroyo and Ramsey [12], would indicate a firmware change.

AC

• Rogue device attacks: The Bluetooth Low Energy protocol requires all connectable targets to advertise their presence. Thus, an intrusion detection system could register and send an alert when an unknown device begins to advertise itself in its proximity.

Finally, a jam-based denial mechanism, similar to that in BLE-Guardian [8], could be used to actively block connections that are determined to be malicious. This would extend the functionality of an intrusion detection system to support intrusion prevention. 27

ACCEPTED MANUSCRIPT

10. Conclusions

ED

M

AN US

CR IP T

BLE-Multi is a firmware enhancement to the open-source Ubertooth One platform that can capture multiple Bluetooth Low Energy connections simultaneously. Experimental evaluations of BLE-Multi against commerciallyavailable sniffers on a single active connection demonstrate that it successfully synchronizes to long-lived connections and outperforms the open-source sniffers. BLE-Multi also performs well on multiple connections with varying master-slave configurations. Experiments demonstrate that, even under the most challenging configuration involving multiple masters and multiple slaves, BLE-Multi successfully captures the majority of the traffic in both connections while outperforming a Ubertooth One that is tuned to a single connection. BLE-Multi is a viable auditing solution for wireless sensor networks that have many sensors communicating simultaneously. A single BLE-Multi sniffer could track and listen to active conversations and create logs that an administrator or security professional could audit for anomalous or malicious activity. While the logs would not actively defend the deployed sensors, they would reveal attacker activity in the wireless sensor networks. As such, they could serve as the foundation for developing automated defensive tools for Bluetooth Low Energy devices and wireless sensor networks. Note that the views expressed in this paper are those of the authors and do not reflect the official policy or position of the U.S. Air Force, U.S. Army, U.S. Department of Defense or U.S. Government.

PT

Acknowledgement

CE

This research was partially supported by the U.S. Department of Homeland Security Industrial Control Systems Cyber Emergency Response Team (ICS-CERT).

AC

IMPORTANT NOTE TO IJCIP TYPESETTERS: I have checked and edited the references in this paper myself. Please DO NOT MODIFY the references – except to add hyperlinks. Please contact the Journal Manager Ms. Ramya Vasudevan if you have any questions. Professor Sujeet Shenoi, Editor-in-Chief, IJCIP

28

ACCEPTED MANUSCRIPT

References [1] Abracon, ABMM Ceramic Surface Mount Processor Crystal, Santa Margarita, California, 2012.

CR IP T

[2] Bluetooth Special Interest Group, Specification of the Bluetooth System, Covered Core Package Version 4.0, Master Table of Contents and Compliance Requirements, Specification Volume 0, Kirkland, Washington, 2010.

AN US

[3] Bluetooth Special Interest Group, Specification of the Bluetooth System, Covered Core Package Version 4.2, Master Table of Contents and Compliance, Specification Volume 0, Kirkland, Washington, 2014.

[4] D. Cauquil, BtleJuice: The Bluetooth Smart MITM framework, presented at DEF CON 24, 2016. [5] A. Chang, Your door is about to get clever: 5 smart locks compared, Wired, June 19, 2013.

M

[6] Cypress Semiconductor, CYW20702 Single-Chip Bluetooth Transceiver and Baseband Processor, San Jose, California, 2016.

PT

ED

[7] S. Das, K. Kant and N. Zhang, Introduction to Part III: Security for sensor networks, in Handbook on Securing Cyber-Physical Critical Infrastructure, S. Das, K. Kant and N. Zhang (Eds.), Elsevier, Amsterdam, The Netherlands, pp. 223–225, 2012.

CE

[8] K. Fawaz, K. Kim and K. Shin, Protection privacy of BLE device users, Proceedings of the Twenty-Fifth USENIX Security Symposium, pp. 1205–1221, 2016.

AC

[9] A. Gogic, A. Mujcic, S. Ibric and N. Suljanovic, Performance analysis of Bluetooth Low Energy mesh routing algorithm in case of disaster prediction, International Journal of Computer, Electrical, Automation, Control and Information Engineering, vol. 10(6), pp. 1041–1047, 2016.

[10] Great Scott Gadgets, Software, Firmware and Hardware Designs for Ubertooth (github.com/greatscottgadgets/ubertooth), 2010.

29

ACCEPTED MANUSCRIPT

CR IP T

[11] Z. Guo, I. Harris, L. Tsaur and X. Chen, An on-demand scatternet formation and multi-hop routing protocol for BLE-based wireless sensor networks, Proceedings of the IEEE Wireless Communications and Networking Conference, pp. 1590–1595, 2015. [12] J. Gutierrez del Arroyo and B. Ramsey, How do I “BLE hacking?” presented at DEF CON 24, 2016.

[13] R. Heydon, Bluetooth Low Energy: The Developer’s Handbook, Pearson Education, Upper Saddle River, New Jersey, 2013.

AN US

[14] K. Higgins, Anatomy of a “cyber-physical” attack, Dark Reading, January 14, 2015.

[15] J. Hughes, J. Yan and K. Soga, Development of wireless sensor network using Bluetooth Low Energy (BLE) for construction noise monitoring, International Journal of Smart Sensing and Intelligent Systems, vol. 8(2), pp. 1379–1405, 2015.

M

[16] S. Jasek, Gattacking Bluetooth Smart devices, presented at the Black Hat USA Conference, 2016.

ED

[17] H. Kim, J. Lee and J. Jang, BLEmesh: A wireless mesh network protocol for Bluetooth Low Energy devices, Proceedings of the Third International Conference on Future Internet of Things and Cloud, pp. 558–563, 2015.

PT

[18] A. Mathur and T. Newe, Comparison and overview of wireless sensor network systems for medical applications, Proceedings of the Eighth International Conference on Sensing Technology, pp. 272–277, 2014.

CE

[19] M. Ossman and D. Spill, Building an all-channel Bluetooth monitor, presented at ShmooCon, 2009.

AC

[20] M. Ossman and D. Spill, Project Ubertooth (ubertooth.sourceforge. net), 2014.

[21] A. Rose and B. Ramsey, Picking Bluetooth Low Energy locks from a quarter mile away, presented at DEF CON 24, 2016. [22] M. Ryan, Bluetooth: With low energy comes low security, Proceedings of the Seventh USENIX Conference on Offensive Technologies, 2013. 30

ACCEPTED MANUSCRIPT

[23] B. Sun, L. Osborne, Y. Xiao and S. Guizani, Intrusion detection techniques in mobile ad hoc and wireless sensor networks, IEEE Wireless Communications, vol. 14(5), pp. 56–63, 2007.

AC

CE

PT

ED

M

AN US

CR IP T

[24] Zero Chaos, Real-time Bluetooth device detection with BlueHydra, presented at DEF CON 24, 2016.

31