See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/317063884

Denial of Service Attack on Bluetooth Low Energy

Working Paper · September 2016

DOI: 10.13140/RG.2.2.12059.26407

CITATIONS READS
2 6,152

1 author:

Peter Gullberg
Thales Group
5 PUBLICATIONS   5 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Peter Gullberg on 23 May 2017.

The user has requested enhancement of the downloaded file.

 Denial of Service Attack on Bluetooth Low Energy
Peter Gullberg,
Principal Engineer, Gemalto Digital Banking
peter.gullberg@gemalto.com
Abstract
Bluetooth Low Energy is a promising technology for wireless
communication. The main benefits are that it is energy
efficient and is slowly becoming ubiquitous. We can expect
that the technology will be used in many demanding
applications.
This raises the question whether Bluetooth Low Energy is
suitable for products and services that require high resilience,
robustness and availability.
In this paper we focus on the availability aspects in the
connection setup of Bluetooth Low Energy. We explore an
attack path that allows us to do a denial of service attack on
the connection setup mechanism. We refine the attack
scenario and implement an exploit using the Project
Ubertooth, an open source platform for Bluetooth
experimentation. We then characterize the attack vector using
the Common Criteria attack evaluation methodology.
Our result indicates that it is possible to successfully mount a
denial of service attack that blocks the connection setup on
Bluetooth Low Energy using standard off-the-shelf
components. The consequence of this exploit helps us bring
awareness that Bluetooth Low Energy may not guarantee
availability when an attacker has the motivation and vicinity
access.
Categories and Subject Descriptors
C.2.1 [NETWORK ARCHITECTURE AND DESIGN]: Wireless
communication
C.4 [PERFORMANCE OF SYSTEMS]: Reliability, availability,
and serviceability
General Terms
Bluetooth Smart, Bluetooth Low Energy, Denial of service,
availability, communication Protocol, Ubertooth
1. Introduction
There are many reasons why Bluetooth Low Energy (BLE) [6] is an
attractive protocol. One reason is is its energy efficiency [7, 17]. A
device acting as a slave can run fully operational and communicate
with the master using less than 10uA in average current. This allows
the development of products that can run on small coin-cell battery
for years.
Another reason is the fact that most new computers and mobile
devices support Bluetooth Low Energy. This makes the technology
even more attractive as it is easy to connect a device to the mobile
and devices.
The board space required to integrate Bluetooth Low Energy into
your product is small. Some BLE chips are as small as 2.5x2.5mm
[7].
Based on these favorable conditions, the Bluetooth Low Energy
technology and its deployment allow the internet of things to
happen, as it is possible to integrate wireless communication into
nearly anything.
With the increased adoption of Bluetooth Low Energy, we can
expect to see services that will rely on the availability of BLE. We
can also expect to see the technology in a diverse range of products,
such as in-house control, merchant POS solutions, in-store
communication, or power meters. Basically anything that wants to
communicate at an effective data rates below 100kbit/s.
PayPal Beacon [6] is a communication solution that enables the
customers to use his mobile to pre-order and to pay with when in the
vicinity of a merchant. PayPal Beacon does not require wireless
connection or phone network, it uses BLE to complete the
transaction. The only thing the merchant need to do is to either use
tablet with BLE support or attach a USB-dongle to his computer.
The presentation provided on Square’s “Secure and Private Service
Discovery over Low Energy Bluetooth” [13], shows that Square
intends to use BLE to complete the transaction between cardholder
and the merchant POS.
We also see suppliers that rate the robustness of the Bluetooth Low
Energy as “strong” and suitable for industrial applications [4]. Based
on such guidance, it is likely that we will see industrial applications
using the Bluetooth Low Energy for communication as it is being
attributed with attractive characteristics.
The early problems with the weak pairing mechanism that was
discovered by Mike Ryan [9] and has since then been corrected in
the Bluetooth Low Energy Specification 4.2 [6] allows secure
pairing between devices.
In conclusion, we can expect that the industry will use widely use
BLE where intercommunication is required.
In the following sections we introduce the reader to the Bluetooth
Low Energy protocol and the connection setup; study related work;
perform threat modeling on the connection mechanism; architect an
attack scenario; we implement the exploit; and finally we present
the analysis, discussion, conclusion and future work.
2. Bluetooth Low Energy background
Bluetooth Low Energy is a wireless protocol that was developed to
allow communication at ultra low power consumption with a low
data rate between a master and a slave and to re-use as much as
possible of the Bluetooth classic radio interface.
A product that incorporates Bluetooth Low Energy technology is
referred to as Bluetooth Smart.
Bluetooth Low Energy is a pure master slave protocol, where the
master always initiates data communication. The protocol has been
designed to be able to operate on a coin-cell battery. The notion is
that the slave is in a low-power mode most of the time.
All these efforts make it possible to operate on a very low average
current.
2.1 Air interface
BLE offers wireless communication in the 2.4GHz frequency band
with data rates of 1M symbol/s using GFSK modulation. The
protocol uses 40 RF channels with a spacing of 2 MHz. Three out of
these 40 channels are used for advertising (37, 38, and 39), the
remaining channels are used for data communication. BLE provides
a simplified channel hopping mechanism compared to basic
Bluetooth, and the hopping sequence is split into connection
intervals where both sides align to the hopping sequence.
2.2 Air interface format
Packets in the air have a fixed structure where data is sent with the
Least Significant Bit (LSB) first.
The air packet interface starts with a Preamble of 1 byte (octet), after
that comes 4 bytes of Access Address, and between 2-39 bytes of
Protocol Data Unit (PDU). Finally a 3 byte cyclic redundancy check
(CRC) is added.
Figure 1 Air interface packet
2.3 Packet interface format
The PDU in the air packet from Figure 1 is split into Header and
Payload, as shown in Figure 2.
Figure 2 Advertising PDU
The Header from Figure 2 is explained in Figure 3, and consists of
a PDU_Type, four reserved bits (RFU), TxAdd and RxAdd, which
defines if the corresponding address is public or random and then
we have a 6 bit length that defines the length of the payload.
Figure 3 PDU header
The PDU Type defines the advertising packet type.
Figure 4 PDU Type
2.4 Packet timing
Between two consecutive packets on the same channel index in
BLE, there is a strict inter frame time defined by the parameter
T_IFS (Inter Frame Space) that is 150µs +/-2µs. This is the time
interval calculated from the last data bit on the previous packet to
the first data bit on the following packet.
T_IFS
Figure 5 Inter frame space
T_IFS = 150µs +/- 2µs.
2.5 Resolvable private addresses
Figure 6 Format of a resolvable private address
BLE supports a feature that prevents and observer to track a device.
This is done by using a private address that is changed on frequent
basis. To resolve a private address, the other device needs use the
Identity Resolving Key (IRK) that is part of the Long Term Key.
The resolvable private address is the concatenation of a hash value,
a random value (prand), and two bits that indicates that it is a
resolvable private address.
The hash value is calculated from has of the IRK and prand.
ℎ𝑎𝑠ℎ = 𝑎ℎ(𝐼𝑅𝐾, 𝑝𝑟𝑎𝑛𝑑)
2.6 Advertisement indication
Advertising is the mechanism that enables the slave to be found by
the master, and is the first step in the process to connect with each
other.
The advertisement indication is a notification sent from the slave to
the master that the slave is ready to be connected with. The payload
contains the advertisement address (AdvA), this is needed as the
advertisement is sent with the broad cast access address that has the
value of 0x8E89BED6. The Advertisement data is optional and
contains information about the device.
Figure 7 Advertisement indication payload
2.7 Connect request
The connect request is a message from the master to the slave. The
payload data in the connect request are initiator address (InitA),
advertising address (AdvA) and LLData, which defines the
communication options, such as connection interval and hopping
sequence. The connection interval can be in the range from 7.5ms to
4000ms.
Figure 8 Payload for the connect request
Figure 9 LLData in the connect request
2.8 Advertisement and channel setup
When a slave is ready to accept a connect request, it advertises in
each advertising channel as shown in Figure 10. If the slave receives
a connect request from a master in response to the advertisement
indication, both will switch over to the data channel, and will touch
base at each connection interval in what is called the anchor point.
As an intermediate step, the master may also send an inquiry request
before the connect request.
Figure 10 Advertisement and connection interface
When the master connects to the slave through the advertising
channel, the master includes the hopping sequence and the
connection interval. These parameters are used to wake-up the slave
in order to communicate at each given connection interval. Each
connection interval uses a unique channel calculated using the
hopping sequence. The slave listens to the master, and when the
connection interval is completed the slave may go back into sleep
until next connection interval.
Within one connection interval, it is possible to send multiple
packets as long as the communication is terminated before next
connection interval starts.
2.9 Connection flow
The sequence diagram in Figure 11 shows how a master and slave
interact with each other.
Figure 11 typical connection sequence
When a master is in the initiating state it actively listens for slaves
that are advertising, in one advertising channel at a time, for the
entire duration of the scanWindow.
The scanInterval is the interval between two consecutive scan
windows. For each scanWindow, the Link Layer should scan a
different advertising channel and all advertising channels must be
processed by the master. The scanWindow must be less or equal
than scanInterval, which must be less or equal than 10.24s. If the
scanInterval and scanWindow are the same, the master will scan
continuously.
𝑠𝑐𝑎𝑛𝑊𝑖𝑛𝑑𝑜𝑤 ≤ 𝑠𝑐𝑎𝑛𝐼𝑛𝑡𝑒𝑟𝑣𝑎𝑙 ≤ 10.24s
When a master finds a slave that advertises, it may send a scan
request to the slave, to learn more about slave. If the master do not
get any response, the master must implement a function called
“back-off procedure” to handle inquiry scan collisions. The
procedure uses a backoffCounter and an upperLimit, that are both
initially set to one. Each time the master receives ADV_IND or
ADV_SCAN_IND, the master decreases the backoffCounter. When
the backoffCounter reaches zero the master sends a SCAN_REQ.
Each time the master fails to receive a SCAN_RSP twice, the master
doubles the uppperLimit until it reaches 256. The master then selects
a pseudorandom value for backoffCounter that is between one and
upperLimit and uses that in the back-off procedure. For each two
consecutive successful SCAN_RSP have been received the
upperLimit shall be divided by two.
3. Related work
3.1 Jamming Bluetooth signals
There is not a lot of research in the jamming of Bluetooth Low
Energy, therefore we include some work in Bluetooth classic.
Steven Köppel did a master thesis around Bluetooth classic jamming
[1], using Ubertooth to follow connections and jam the connection
with noise.
To jam a Bluetooth signal, it is necessary that the jamming signal is
strong enough to severely cripple the Bit Error Rate (BER). Most
Bluetooth classic demodulation algorithms can operate at a Signal
to Noise Ratio (SNR) of about 15dB with a BER of 0.1% [2].
For Bluetooth Low Energy the Co-Channel interference is specified
to 21dB [6], but chip suppliers are likely to have a better SNR than
this. In order to jam a signal we need to make sure the signal we
transmit is strong enough to affect the BER. As we increase the
jamming signal strength it will increase the BER until the point
where the receiver cannot correctly receive packets from the other
side.
3.1.1 Calculating the jamming distance
To calculate the jamming distance, we start by calculating how
much signal is lost in the air. We use a simplified formula known as
Friis transmission equation, used to calculate the path loss [8]
between two isotropic antennas:
4𝜋𝐷
𝐿 = 20 𝑙𝑜𝑔10 ( )
𝜆
Equation 1 Friis transmission equation
L is the path loss (dB), D is the distance between transmitter and
receiver measured in meters, λ = wavelength in meters. For BLE λ
is 0.125 meters (f=2.4 GHz)
If we want to jam a device, the difference between the signal from
the master and the jamming signal must be significantly less than
21dB, when received by the slave.
4𝜋𝐷 4 𝜋 0.5
21𝑑𝐵 ≫ 20 𝑙𝑜𝑔10 ( ) − 20 𝑙𝑜𝑔10 ( )
0.125 0.125
Equation 2 Calculating jamming distance
Let us assume that the distance is 0.5 meter between the slave and
the master we want to jam. If we also assume that the master and
our device have identical transmission properties, we can use
Equation 2 to calculate the difference in path loss between the two
masters and the receiver.
We can now determine that our device must be significantly closer
than 5.6 meter to the slave in order to affect the BER.
Then depending on the transmitter output and receiver sensitivity
and antenna performance we can calculate the link budget:
𝐿𝑖𝑛𝑘 𝐵𝑢𝑑𝑔𝑒𝑡 = 𝑃(𝑡) + 𝐺(𝑡) + 𝐺(𝑟) − 𝑅(𝑠) − 𝐹(𝑠)
P(t) is the transmitter output, G(t) is the transmitter antenna gain, represents the trust boundary between the master and the slave. You
G(r) gains of the receiver antenna, R(s) receiver sensitivity and F(s) can also see three main blocks on each side that represent the
fading margin dB. All values are in dB. functional states that shows the high level view on the connection
functionality. Starting from top is the connection phase that uses
3.2 Common Criteria white list data, in the middle is the authentication phase and finally
The attack rating evaluation methodology used in Common Criteria in the bottom is the communication phase, that both uses the long
[11] is used to rate attacks using five criteria’s. The criteria’s are term key. It is only after the authentication phase has completed that
quantified in Table 1, where we decided to use the exploitation both sides have authenticated each other, and after that exchange
values for both the identification and the exploitation phase. data between each other in encrypted mode.
Knowledge of Access to
Elapsed time Expertise Equipment There are some revealing discoveries on the BLE security [9, 12]
the TOE the TOE
0: <0.5 hour 0: Layman 0: None 0: <0.5 hour 0: None
that demonstrates the possibility to intercept and crack the pairing
3: <1 day 2: Proficient 2: Public 4: <1 day 2: Standard
security in BLE. In this paper we do not consider any logical security
5: < 1 month 4: Expert 4: Sensitive 6: < 1 month 4: Specialised
aspects.
8: > 1 month 6: Very sensitive 9: > 1 month 6: Bespoke 4.2 Analyzing the data flow diagram
Table 1 Criteria rating When studying the data-flow-diagram in Figure 12 in combination
with Figure 11, it is clear that the advertisement and connect
happens before any side have authenticated the other. By analyzing
Elapsed time defines how much time is required to identify or the potential threats using threat modeling, we discover that it is
exploit the attack. possible for an attacker to either advertise with an advertisement
Expertise, defines the expertise required to complete the step. address (AdvA) that belongs to a slave, or connect to a slave with
an initiator address (InitA) that belongs to a master. In this way the
Knowledge of the Target Of Evaluation (TOE) is the knowledge the attacker can chose to impersonate either the master or the slave at
person requires to successfully complete the attack step. this initial step, as neither entity can authenticate the other.
Access to TOE, defines how long time the attacker has to the system. If we impersonate the slave, we could trick the master to connect to
If the attacker can perform his attack undetected, this value should our slave instead of the genuine one. Looking at the sequence
be zero. diagram in Figure 11 we recall that the advertisement is the first to
To calculate the attack rating of a certain attack vector, two separate occur, therefore we first have to discover the slave before we can
attack step calculations are done. The first is the initial discovery impersonate it.
phase and the second is the exploitation phase. These are added to If we impersonate the master, we can connect to a slave that is
get the attack rating. advertising and stall the authentication process thereby blocking one
The attack rating is then calculated from the sum of the initial specific slave device. If you look in the white list of the device, it
identification and exploitation phase. If the attack rating is in the might turn out that you need to provide an InitA that is already
range 0-10, it is defined as “no rating”, if the attack rating is 10-17 known otherwise the slave may not respond at all. The white list is
it is defined as “Basic”, and 18-24 is defined as “Medium”, and used prevent unknown devices from connecting with the device, and
finally >24 or higher is defined as “High”. also to reduce power consumption by not processing requests from
unknown devices.
4. Threat modeling
To identify potential threat in BLE, we perform a threat modeling However, looking at the one of the popular BLE chips [10] we
on the connection setup mechanism. The threat modeling is based discover that the white list mechanism cannot contain resolvable
on Microsoft threat modeling [16] and instead of using dread to rate private addresses, as the chip do not seem to have the capacity to
the vulnerabilities we use Common Criteria. resolve the private address in real-time with the narrow timing that
is required in BLE. It is likely that other BLE chips may have similar
4.1 Visualizing the connection setup behavior.
Therefore it is only after the authentication process has completed
that the devices know that they are talking with the correct entity.
ADV_IND
Master
This provides an interesting attack vector and a potential
Slave
connection
connection vulnerability. Therefore we decide to investigate this threat further
in the coming sections. As long as the slave cannot resolve the
WHITE LIST
WHITE LIST
CON_REQ address in real-time, we can randomly chose a private address.

Authenticate
Master
4.3 Denial of Service identification
Slave
authentication Authentication Based on the findings from the threat modeling in the previous
Authenticate
section we continue to investigate the ability for the attacker to
LONG TERM LONG TERM impersonate a master and perform a denial of service attack on
KEY KEY
Encrypted data
protocol level to block the legitimate entities to communicate with
Master
each other by impersonating the master and connect to the slave.
Slave
communication
communication As we explained earlier if we use a private resolvable address, the
Encrypted data
slave cannot distinguish between our malicious master and a
legitimate master in this first step.
At this point we could start to communicate with the slave, and stall
the authentication process to prevent the slave from understanding
that we are not the right master. This would require us to have one
Figure 12 Data-flow-diagram malicious BLE master for each slave we want to block.
We start by doing a data-flow-diagram as seen in Figure 12. We
analyze the trust levels, data flow and show the functions of the BLE
connection setup mechanism. On the right side you have the master,
and on the left side you have the slave. The red horizontal line

Figure 13 Denial of service attack
Instead we prefer to further enhance the attack. In our enhancement,
we do not enter the connect state with our malicious master, as we
are supposed to do. Normally the master should follow the hopping
sequence with the defined connection interval, and the slave must
follow the master. The master will not send any data in the
connection interval, as shown in Figure 13 with a crossed out
master-slave packet.
Even if the master ignores to enter the connection state, the slave
still has to enter the connection state dictated by the master, and must
assume that the master will send data at the anchor point of each
connection interval. The slave will obviously not find the master.
The slave must keep trying to find the master for 6 connection
intervals before the slave fails the connection. Section 4.5.2, in vol.
6 of the Bluetooth Specification mentions that “If the Link Layer
connection supervision timer reaches 6 * connInterval before the
connection is established (see Section 4.5), the connection shall be
considered lost. This enables fast termination of connections that
fail to establish.”
This means that a slave should not start advertising again until it has
correctly detected link loss.
Another reason for doing this enhancement is that it frees our
malicious master, which is able to listen to advertisements from
other slaves.
5. The exploit
To develop the exploit, we decided to use the Project Ubertooth [3],
and the Ubertooth One hardware, where we based our work on
version ubertooth-2014-02-R1. For our experimentation we
purchased the Ubertooth One at an online web-store for less than
100€ and received the package the day after.
5.1 Project Ubertooth
The Project Ubertooth is a 2.4 GHz wireless development platform
intended for Bluetooth experimentation that supports both Bluetooth
classic and Bluetooth Low Energy.
It is open source and contains everything required to build the full
Bluetooth experimentation platform. All parts including software,
firmware schematics, pcb-layout and bill of material are freely
downloadable from the ubertooth web-site, even the development
tool chain is freely available.
The platform allows monitoring and following both Bluetooth
classic and Bluetooth Low Energy connections. As every part is
open source, it also allows us to develop our own exploit.
5.1.1 Ubertooth One hardware
The Ubertooth One hardware contains an LPC1756 ARM Cortex-
M3 microcontroller [14], which also contains a full speed USB
interface that interfaces with the PC. The CPU runs with an internal
PLL that enables the CPU to operate at up to 100MHz. The wireless
transceiver is a 2.4GHz transceiver CC2400 [15] and has a 16MHz
crystal, and connects to an analog RF front end CC2591 that is able
to boost the output signal to +22dBm. The RF output is through a
RP-SMA connector, where you can attach your antenna. In our case
we use a Rubber duck antenna with 2.2dBi.
Figure 14 Ubertooth One hardware
5.1.2 Software
The software runs on the PC and interfaces with the firmware.It is
used to monitor and control the Ubertooth One. We can run the
software on several platforms, but in our experimentation we choose
Ubuntu 12.04.
5.1.3 Firmware
The firmware runs inside the Ubertooth One. The main purpose of
the firmware is to handle the low level and time critical processing
of the Bluetooth protocol. The firmware also handles the interface
to the PC through USB.
When sending or receiving BLE data, the firmware interfaces with
the CC2400 transceiver and handles every piece down to the bit
level, including timing. When a data block has been received it
transfers it upstream to the host.
5.2 Building the exploit
The exploit we want to build is simple and straight forward.
As shown in Figure 13, we listen for advertisement indications
broadcasted in the advertisement channel. When we receive an
advertisement indication we wait for a time period of T_IFS. After
the timeout period we send our crafted CONNECT_REQ as
response to the advertisement indication. After we have sent the
CONNECT_REQ, we restart the process.
START
RECEIVE
ADV_IND
WAIT
T_IFS
SEND
CONNECT_REQ
Figure 15 Denial of service process flow
In the CONNECT_REQ we specify a high connection interval. The
slave will then have to wait 6*connInterval before connection fails.
When the connection fails, the slave may go into sleep or retry to
advertise.
5.3 Implementing the exploit
Ubertooth One firmware implements the main parts of the low-level
of Bluetooth in the file bluetooth_rxtx.c. We based our development
on the code that handles the BLE follow mode.
One of the first modifications was to implement a precise timing to
control the timing between the packets we receive and the packets
we send. To get this timing, we use the CLK100NS clock macro that
gives us a timer with a granularity of 100ns, but the overall timing
is less than that.
The function bt_le_sync() searches for BLE packets and feeds them
to the PC. This is done by first looking for a valid preamble and the
access address. It then continues to receive the data. After finished
receiving the data, it sets the timer T_IFS, and then perform de-
whitening and verifies the crc checksum. If the crc is correct, the
function calls the packet callback handler and then transmits the
packet to the PC. After this it continues to search for more BLE
packets.
We modified this to call our own call back handler that generates
the connect request and transmits the connect request block.
In our packet handler, we check that it is an advertisement
indication, if not, we stop processing. After that we extract the
relevant parameters, such as AdvA and then construct a connect
request containing the extracted parameters, including predefined
default values and call the le_transmit() to broadcast the connect
request in response to the advertising indication.
We modified the le_transmit() to wait until T_IFS timeout before
we start sending the packet.
We also optimized some parts of the implementation as all the
processing from receiving the packet to start of transmission was not
fast enough.
5.3.1 Compiling and loading the exploit
We compile the firmware by simply typing “make”. Project
Ubertooth have conveniently prepared all the make files.
We then sign the compiled binary using the ubertooth-dfu tool.
ubertooth-dfu –sign bluetooth_rxtx
This creates the pdu file that we can load to the target, which is the
Ubertooth One. We do this with the command:
ubertooth-dfu –write bluetooth_rxtx --detach
Now when we have loaded the firmware to the target, and the
Ubertooth One is ready for exploitation.
6. Exploitation
6.1 Exploitation setup
In order to test the exploit, we setup a test scenario.
For the malicious master, we use the Ubertooth One with the exploit
that we detailed in previous section. We configure the malicious
master to use channel 37 and to reply to any ADV_IND with a
CONNECT_REQ, with the connInterval parameter set to 400ms. As
we do not follow the slave into the connection state, we expect that
the slave will lose connection after 6 x connInterval, which is 2.4
seconds. The exploit returns all BLE packets it detects.
For the slave, we use a standalone evaluation board, see Figure 16.
Figure 16 CC2541 evaluation board
The slave device uses a CC2541 chipset and contains two buttons
and a small coin cell battery. The firmware running inside the slave
is a small test application. The application starts advertising as soon
as the right button is pressed once. Pressing the button again will
stop advertisement. If the application loses connection it will restart
advertising. To visually distinguish between the advertising state
and the connect state, we connect a LED to the board. The LED
blinks each time the device advertises. The advertising interval is set
to 100ms.
For protocol analysis of BLE, we use the Texas Instrument SmartRF
Packet Sniffer together with a USB dongle using a CC2541 BLE
chip (not shown). We configure the protocol analyzer to capture
channel 37 and to not follow connections. After that we start the
protocol analyzer to capture packets.
We start the malicious master (Ubertooth One) with the following
command line:
ubertooth-btle –f
This command starts the denial of service exploit.
6.2 Exploitation test
The test starts by pressing the right button on the slave device. We
notice a short blink that repeats itself over and over again. We let
the slave run for approximately one minute, and then stop the test
by pressing the button again. We then stop the protocol trace and
save the recorded data.
7. Analysis
7.1 Analyzing the test result
Looking at the recorded protocol trace in Figure 17, we see the
advertising event in packet number 15, and the corresponding
connect request from the master in packet number 16. After that
there is a delta time of +2,554,556µs before we see the next packet,
which is another advertising indication. This matches well with the
expected link loss timeout of 2.4 seconds and a 100ms advertising
interval time. After this, we see that the malicious master repeats
and sends a connect request to each advertising indication.
Figure 17 BLE protocol trace
Figure 18 contains the complete data of the first ADV_IND packets,
and in Figure 19 the complete data view of the first
CONNECT_REQ packet.
Figure 18 ADV_IND

Figure 19 CONNECT_REQ
7.2 Attack rating using Common Criteria
Based on the exploit, we estimate the attack rating for both the
identification and the exploitation phase.
It is normally more complex to identify and develop the attack than
it is to exploit it, therefore the identification of an exploit and the
actual exploitation are separated with individual ratings.
Elapsed time, to identify and develop the exploit requires us to spend
more than 1 month of work. The exploitation can be performed in
less than 0.5 hour.
Expertise, we estimate that the expertise level required for
identification is expert, while the exploitation can be performed by
a layman.
Knowledge on TOE, the identification requires only public
information. Exploitation requires no knowledge on the TOE.
Access to TOE, we can use any TOE for the identification. For the
exploit, our exploit can be hidden in any place in the vicinity of the
TOE, meaning we can go undetected.
Equipment, the Ubertooth One is considered standard equipment, as
it can be bought from several online stores and even built from
information downloadable from the internet.
We summarize the criteria for the identification and the exploitation
phase in Table 2.
Table 2 Attack rating
Total point score identification and exploitation of this attack is 18
and 2 for exploitation.
7.3 Estimating the success rate
In our experiment we performed a test using using one malicious
master running on channel 37.
We want to estimate the theoretical success rate of the denial of
service attack when using three malicious masters, one for each
channel. In order to do this, we need to make a number of
assumptions.
7.3.1 Assumptions
To be fair, we assume favorable settings for the master in order to
maximize its possibility to successfully connect with the slave.
In our fairness to the master, we assume the master uses
scanWindow = scanInterval = 100ms. We then use a slave
advertising interval of 100ms, where the slave must advertise in all
channels within those 100ms. In such scenario, we assume the
master is able to find the slave within one scanInterval. For
simplification, we ignore the scenarios when a slave sends an
advertisement that overlaps two scan windows.
Further the assumption is that we have three malicious masters
running the exploit on each advertising channel 37, 38 and 39.
In addition we assume that our malicious masters and the slave are
in range (vicinity), and that the malicious masters are able to respond
to all advertisements that they receive in their respective channel.
We also take into account jamming, where we assume two extremes,
either we can successfully jam or we cannot jam. If we can
successfully jam, it might be that the malicious master is strong
enough to even win. This means that the malicious master needs to
be significantly closer than the master to the slave.
In any given instance the master will be listening in one slot out of
three, and at the same given time, the malicious masters will be
listening in all three slots.
Further we assume that the slave is incapable of using the white list
with resolvable private addresses.
Further we take as assumption that when the slave receives a connect
request it will immediately stop advertising and enter connection
state.
7.3.2 Estimations
Based on these assumptions above, we estimate the theoretical
denial of service success rate.
For each transmitted advertisement indication sent by the slave, the
master has in average 33% chance of receiving the advertisement,
as the master at any given time only listen to one advertisement
channel. The three malicious masters on the other hand have
together 100% chance of receiving the same advertisement.
In the case we cannot jam the master, our malicious masters can
theoretically reach a denial of service success rate of 67%.
In the case we can jam the master we can theoretically reach 100%
success rate. In 67% of the cases as detailed above we successfully
connect immediately, but for the remaining 33%, our malicious
master will send a packet that jams the master, resulting in that the
slave will not respond. If the master fails to receive a response from
the slave twice, the master must do the back-off procedure, and will
not be allowed to respond to the slave on subsequent advertisements.
In the subsequent advertisement our malicious masters can send a
successful connect request.
8. Discussion
In this exploit the attacker sends a connect request that stalls the
communication on the slave until the Link Layer Connection
Supervision timer expires. In our experiment we used a timeout of
2.4 seconds, but the BLE specification allows us to extend it to 24
seconds. Our result demonstrates that it is possible to impersonate a
master.
In addition we discovered that certain BLE chips are unable to use
the white list and resolve the private address in real time. This
greatly simplifies the attack vector, as we do not need to know the
masters initiator address (InitA) in advance, before connecting to the
slave.
The BLE specification defines that the master should only listen in
one advertisement channel at a time. As the master and the slave are
not synchronized, this means that the slave will have to send in
average three advertisements before the master receives it. This
gives the attacker an advantage over the master, as he can listen on
all three advertisement channels at the same time. The attacker can
send a connect request to the slave and reach a theoretical success
rate of 67%, even if attacker is unable to jam the master.
Our experiment was limited to one malicious master in channel 37.
Since the exploit operate independently in each channel, it would
require very little effort to scale up the attack to cover all three
channels.
If the attacker in addition is able to jam the master, the attacker can
theoretically reach 100% denial of service, as the master must
implement the back off procedure as defined in BLE specifications.
However, this has not been demonstrated in this paper, as we have
only briefly covered signal jamming.
Although it takes a great deal of knowledge to identify the exploit,
it is possible to perform the exploit using only simple means.
 If the master would be capable of listening in all channels
simultaneously this would reduce the attack surface. In such case the
attacker must be able to jam the master in order to succeed.
Another way to reduce the attack surface would be if the BLE chip
is able to resolve the private address in real-time, or if the BLE chip
resolves the private address from the application layer after
connection. If the address does not match the stored address, it can
restart advertisement. However, this mitigation would only be
effective if the attacker is unable to jam the master, as soon as the
advertisement restarts, the attacker would jam the connection.
The denial of service attack can be seen as a completed attack vector
or as a sub-goal. If the motivation is to do financial harm this exploit
indicates that it is possible to use this method to block
communication, and thereby threaten the availability. If the
motivation is to do financial gain, we can see this exploit as a sub-
goal, where we block communication for a particular user until the
point, where the user initiates a new pairing between the master and
the slave. By the time that happens, we may have sufficient
information to do financial gain.
9. Conclusions and future work
9.1 Conclusions
One of the main findings in this paper is that we analyzed the
connection setup mechanism and discovered a weakness in the BLE
protocol that makes it possible for a malicious master to connect to
a slave. We also discovered that some BLE chipset do not provide
real time resolving of private addresses, and therefore makes them
vulnerable to this attack.
We conducted a threat modeling with the focus on availability and
denial of service of Bluetooth Low Energy. As a result of the threat
modeling we identified a potential vulnerability where we can
impersonate a BLE device. We developed an exploit, and
demonstrated the vulnerability. Based on the exploit, we rated the
effort required to identify the vulnerability and then to perform the
exploitation using Common Criteria.
Our result shows that it is possible to disturb Bluetooth Low Energy
on the protocol level and that it can be used to threaten the
availability of a system.
The conclusion is that once an exploit has been developed, it is easy
for a layman to acquire the necessary equipment and setup an attack
in a short time with an exploitation score of 2 that is considered low.
One of our conclusions is that anyone that develops systems that
uses Bluetooth Low Energy communication needs to consider the
availability aspects of their solution, as this may not be guaranteed
if the attacker has vicinity access.
9.2 Future work
Future work can be focused on establishing the success rate between
a malicious master and a master.
There are several aspects of the exploit that can be enhanced. Our
implementation only covers ADV_IND. Future work can be to
extend the implementation to also cover other advertisement types.
In case a slave can handle concurrent sessions by the same slave
there might be a need to have random access addresses.
When it comes to the attack scenarios, these could be enhanced as
well. We did not explore a full attack scenario, where we attack all
three advertising channels at the same time. The exploit has not been
tested in public space, further the exploit has only been tested
against one BLE chip. Future work could be focused on classifying
different types of BLE chip.
View publication stats
Another direction of work would be to explore the jamming
capabilities, trying to extend the jamming distance by increasing the
output power, and to determine the attenuation of the BLE master in
different situations, such as when a user covers the antenna with his
hand.
Simplifying the acquisition of the exploit is another direction. The
current exploit requires both Ubertooth One and a PC to function.
To implement the same attack using off-the-shelf Bluetooth Low
Energy chips would make the attack significantly easier to mount.
10. References
[1] Köppel S., 2002, Bluetooth Jamming, Bachelor's Thesis,
Computer Engineering and Networks Laboratory, ETH
Zurich, ftp://ftp.tik.ee.ethz.ch/pub/students/2012-HS/BA-
2012-16.pdf, retrieved 204-02-10
[2] Schiphorst R., Hoeksema F. Slump K. 2002, Bluetooth
demodulation algorithms and their performance, 2nd
Karlsruhe Workshop on Software Radios, pp. 99-106
[3] Project Ubertooth, http://ubertooth.sourceforge.net
[4] http://www.connectblue.com/fileadmin/Connectblue/Web200
6/Documents/White_papers/Industrial_Bluetooth.pdf
[5] PayPal Beacon
https://www.paypal.com/webapps/mpp/beacon, Retrieved
2014-03-25
[6] Bluetooth Core 4.1 and 4.2 specification
[7] DA14580, Bluetooth Low Energy chipset, http://www.dialog-
semiconductor.com/docs/site-pdf/da14580_pb.pdf, 2014-03-
25
[8] Wikipedia on pathloss, http://en.wikipedia.org/wiki/Path_loss,
Retrieved 204-02-08
[9] Ryan M.,
https://www.usenix.org/sites/default/files/conference/protecte
d-files/ryan_woot13_slides.pdf, Retrieved 2014-02-08
[10] CC2541 Bluetooth Low Energy controller
www.ti.com/product/cc2541, Retrieved 2014-02-08
[11] Common Methodology for Information Technology Security
Evaluation, CEM2.3
[12] Rosa T, Bypassing Passkey Authentication in Bluetooth Low
Energy, IACR Cryptology ePrint Archive,
DBLP:journals/iacr/Rosa1
[13] Perito D., Secure and Private Service Discovery over Low
Energy Bluetooth, Square, Real world crypto workshop,
http://realworldcrypto.files.wordpress.com/2013/06/perito.pdf
[14] LPC1756 data sheet
http://www.nxp.com/documents/data_sheet/LPC1759_58_56_
54_52_51.pdf, retrieved 2014-02-10
[15] CC2400 2.4GHz transceiver
http://www.ti.com/lit/ds/symlink/cc2400.pdf , SWRS042A,
Retrieved 2014-02-10,
[16] Microsoft threat modeling http://msdn.microsoft.com/en-
us/library/ee823878(v=cs.20).aspx, retrieved 2014-02-18
[17] Siekkinen M., Hiienkari M., Nurminen J., Nieminen J., How
Low Energy is Bluetooth Low Energy? Comparative
Measurements with ZigBee/802.15.4,
DOI:10.1109/WCNCW.2012.6215496