Detecting and preventing Bluetooth Low Energy Attacks...security establishment, and others. Addresses Bluetooth Low Energy devices use addresses to recognize each other. The BLE addresses

Detecting and preventing BluetoothLow Energy Attacks

Cristian Munteanu, Balint Szente, Gyula Farkas

Bitdefender

[email protected], [email protected], [email protected]

April 16, 2020

Abstract

Over the last two years or so a large number of research papers and presentations on security flaws in BLEdevices came out. By far, the most prevalent hacks against BLE involve capturing handshakes, hard-coded keysand replay attacks.

However, these papers and presentations are on the offensive side of this subject, describing different attackson various devices.

Is it possible to detect such attacks and if so, how to stop them? How can the risk of such attacks be mitigatedagainst when vendors are often careless with security when they implement BLE stacks? How to protect theuser’s devices and the users when the BLE protocol fails to do it?

The current paper approaches the defensive angle of this subject, showing different attack models and focusingnot only on the victim’s security flaws, but also on the attacker’s shortcomings. The paper presents ways ofdetecting in real-time various attacks and ultimately shows a new technique aimed to provide a generic defenseagainst MITM and DoS attacks.

I. Introduction

Generic info

Bluetooth Low Energy (BLE) is a wireless protocoldeveloped to allow communication at an extremelylow power consumption level and at a data rate below200kbps [1]. It is a pure master-slave protocol wherethe master always initiates data communication,which reuses as much as possible of Bluetooth classicprotocol. Designed to be able to operate on a battery,BLE relies on the basic principle to keep the slaves ina low-power mode all the time.

The advantages and the attractiveness of BLE areundeniable and this is why it is one of the mostpopular mobile communication protocols.

First, its energy efficiency [2], a device actingas a slave can fully operate and communicate withan average current less than 10uA. This allows theproducts to run on a small coin-cell battery for a fewyears.

Another reason is the accessibility. Most computersand mobile devices support Bluetooth Low Energy,

which makes the protocol more appealing as it is easyto connect a slave device to a master device alreadyon the market.

Besides that, the BLE chips are as small as2.5x2.5mm [3] thus requiring little space on boardfor integration.

The deployment of this technology createdfavorable conditions for the expansion of the internetof things, as it is possible to integrate this wirelesscommunication into nearly anything.

A product that incorporates Bluetooth Low Energytechnology may also be referred to as BluetoothSmart.

Devices

With the growing spread of BLE, we can see nowa variety of devices on the market successfully usingit. Of course, crowdfunding projects are just a smallpart of all implementations, as BLE is making itsway towards medical, industrial and governmentequipment. Wearables, light bulbs, sockets, cups,

1

mailto:[email protected]:[email protected]:[email protected]

Detecting and preventing a Bluetooth Low Energy Attack • April 16, 2020

sensors, medical devices and other smart productsthat surround our lives may not be associated withsignificant risks. However, there are some products(door looks, alarms, security sensors, biometricauthentication, banking tokens, keypasses etc.) thatmay possess serious security implications.

II. BLE Protocol Description

Bluetooth Low Energy communication betweendevices usually follows the same scheme at eachdata/message exchange:

1. Slave device (or peripheral) broadcasts anadvertisement

2. Master device (or central) scans foradvertisements

3. Once a specific advertisement package is found,the central device stops scanning and initiates aconnection to the peripheral.

4. Central device discovers all available services ofthe peripheral.

5. Communication begins using GATT protocol [4].

BLE offers communication in the 2.4 Ghz frequencyband. The protocol uses 40 RF channels with aspacing of 2 Mhz. Three out of 40 channels are usedfor advertising (37, 38, 39) and the rest are for datacommunication.

BLE stack

The Bluetooth low energy protocol stack (orprotocol stack) consists of the controller, the hostand the application. [Figure 1]

The physical layer (PHY) is a 1 Mbps adaptivefrequency-hopping GFSK (Gaussian frequency-shiftkeying) radio operating in the unlicensed 2.4 GHzISM (industrial, scientific, and medical) band.

The Link Layer (LL) is the part that directlyinterfaces with the physical layer and it is usuallyimplemented as a combination of custom hardwareand software and it defines the main role of the BLEdevice.

The Bluetooth specification defines Host ControllerInterface (HCI) as a set of commands and events forthe host and the controller to interact with each other,

Figure 1: BLE Stack

along with a data packet format and a set of rules forflow control and other procedures.

The Logical Link Control and Adaptation Protocol(L2CAP) layer provides two pieces of functionality:

1. it serves as a protocol multiplexer that takesmultiple protocols from the upper layers andencapsulates them into the standard BLE packetformat

2. performs fragmentation and recombination, aprocess by which it takes large packets from theupper layers and breaks them up into chunks

The Attribute Protocol (ATT) is a simpleclient/server stateless protocol based on attributespresented by a device.

The Security Manager (SM) is both a protocol and aseries of security algorithms designed to provide theBluetooth protocol stack with the ability to generateand exchange security keys. This allows the peersto communicate securely over an encrypted link, totrust the identity of the remote device, and finally, tohide the public Bluetooth Address if required to avoidmalicious peers tracking a particular device.

The Generic Attribute Profile (GATT) establishes indetail how to exchange all profile and user data overa BLE connection.

2


The Generic Access Profile (GAP) dictates howdevices interact with each other at a lower level,outside of the actual protocol stack. GAP can beconsidered to define the BLE topmost control layer,given that it specifies how devices perform controlprocedures such as device discovery, connection,security establishment, and others.

Addresses

Bluetooth Low Energy devices use addresses torecognize each other. The BLE addresses borrowthe format of the MAC address, that’s why they arealso called BLE MAC addresses. However, while aBLE device can change its address at will, the MACaddress cannot be modified. This feature is present inBLE devices for hiding and protecting their identity.

Four types of BLE addresses can be distinguished:

• Random Static - This type of address actsalmost like a standard MAC address, as itis randomly generated and does not changeduring the life-cycle of the device. Howeverthe BLE device may change its address after areset/reboot.

• Public IEEE Format - Similar to RandomStatic with one difference. First 24 bits of theaddress are reserved for a specific manufacturerthrough IEEE Authority1 and act as company IDof the device. The last 24 bits are random.

• Random Non-Resolvable - The device with thistype of address randomly generates a differentaddress at a certain time interval.

• Random Resolvable - This method requirespreparation. The devices must exchange theirIRK (Identity Resolving Key) first. In this case,the address is a concatenation of a Random anda Hash value. The Hash is generated using theRandom and the IRK. To check the identity of thedevice, the connecting device will use its own IRKand the Random part of the address to generate alocal Hash. If the Hash values match, the identityis resolved.

The first two types are common in static devices,like light bulbs and smart locks, where the last twotypes are usually found in mobile devices, like phonesand smart watches.

Advertising

Advertising is the process that allows the slave tobe found by the master, being the first step in theprocess of establishing a new connection.

When a peripheral device is powered-up andready to accept a connection request, it will startadvertising on all 3 channels (37, 38, 39). Theadvertisement package contains:

• Package Header• Advertising Address (MAC Address)• Advertising Data, usually containing device

name, other manufacturer specific data, flagsspecifying LE and BR/EDR2 capability andsometimes services.

Meanwhile the master device scans the advertisingchannels. Once the desired advertisement is receivedthe connection process begins.

Listing 1: Advertisement Data

{"localName": "Thingy","manufacturerDataHex": "59002ed519a3","serviceUuids": ["ef6801009b3549339b1052ffa9740042"]

}

Connecting

The central device will now send a CONNECT_REQpackage. A connect request is a message from themaster to the slave. The payload data is:

• Central Address• Peripheral Address• LLData, which defines communication options

such as hopping sequence and connectioninterval

If the slave receives a connect request from amaster in response to the advertisement indication,both will switch over to the data channel and willcontinue the communication using LLData settings.

1. https://standards.ieee.org

2. Technical term for Bluetooth Classic

3


Discovering and Browsing Services

Once the connection has been established, thecentral device will scan for available services andcharacteristics. A characteristic contains a singlevalue (“attribute”), which can be read, written toor subscribed for notifications. Each service andcharacteristic is identified by an associated UUID(Universally Unique Identifier). Typical services(e.g. battery level, device information) use shortUUID values defined in the Bluetooth specification[5]. To create their own proprietary servicesand characteristics vendors have to define theirown long UUID values. In our experiments weused Nordic Thingy:52 developing boards [6] andthey have implemented their series of services andcharacteristics.

Listing 2: Nordic Thingy:52 service example

{"uuid": "ef6801009b3549339b1052ffa9740042","startHandle": 14,"endHandle": 30,"characteristics": [{"uuid": "ef6801019b3549339b1052ffa9740042","name": null,"properties": [

"read","write"

],"value": "5468696e6779","descriptors": [],"startHandle": 15,"valueHandle": 16,"asciiValue": "Thingy"},

{...]

}

Security

Pairing

Pairing or Bonding, is the process through whichtwo connected devices exchange encryption keys

in order to secure their further communication.Currently, on the market, the Bluetooth Smart devicesare running BLE versions 4.0, 4.1, 4.2 and 5.0.

In case of 4.0 and 4.1 devices, the bonding processis called LE Legacy Pairing which uses the BLEstandard key exchange protocol. At first the devicesexchange a Temporary Key (TK) and use it to createa Short Term Key (STK). Next, the STK is used toencrypt the further communication. The security ofthis process depends on the pairing method used toexchange the TK and the STK. Each method has adifferent approach and depends on the capabilities ofthe device.

Devices running versions 4.2 and 5.0 can usea different pairing process, called LE SecureConnections. Instead of TK and STK, this processintroduces the Long Term Key (LTK) to encryptthe connection. Also the LTK is usually exchangedusing Elliptic Curve Diffie Hellman (ECDH) publickey cryptography which prevents an attacker fromsniffing the key. Of course, these devices arebackwards compatible and can pair using LE LegacyPairing as well.

The pairing process can be described in two steps:

• Step One: One of the devices initiates thepairing by sending a "Pairing Request" package,containing a series of information, such as: I/Ocapabilities, maximum key size and a seriesof flags regarding authentication requirements.The connected device will reply with a similarpackage, containing its information. Basically,in this step, devices present each other theirpossibilities and agree on how they are going toproceed.

• Step Two: Since the devices know about eachother’s capabilities, they will choose a pairingmethod that will be used for key exchange.In LE Legacy Pairing, they will generate andexchange the Temporary Key and then, using theTK and a random value, they will create the ShortTerm Key. This STK will be used for followingdata encryption.In LE Secure Connections, both devices willgenerate an ECDH public-private key pair. Thenthey will exchange the public keys. Next theLTK is generated and exchanged using theDiffie-Hilman private key, thus offering a strongprotection against sniffing.

4


In the following section we will describe thepairing methods, mentioning their advantages anddisadvantages against various attacks.

Pairing Methods in LE Legacy Connections

Just Works

In this method, the TK does not exist. Thus, it isvery easy for an attacker to calculate the STK andeavesdrop on the connection. In that case there isno way of verifying what devices are taking part inthe connection and the method is vulnerable to MITMattack.

Passkey

In this method, the TK is a 6 digit number that isverified by the user on both devices. Most of the time,one of the devices generates a random 6 digit numberand displays it on an LCD display. The user wouldeither check the number on both devices or wouldtype in on the keypad/keyboard of the other device.

The passkey method is generally considered to besecure from MITM attacks, however if an attacker islistening during the pairing process, he will be ableto sniff the values being exchanged. After this, he caneasily determine the TK and afterwards the STK.

Out of Band (OOB) pairing

In this method, the TK is exchanged using adifferent technology (Wi-Fi, NFC, QR code, anythingbut BLE). The main advantage to this method is thata very large TK can be used, up to 128 bits, greatlyincreasing the security of the connection. At thispoint, the BLE connection is protected from MITMas long as the OOB channel is protected from MITMattacks. Out of all pairing methods, OOB pairingis considered the most secure, assuming the OOBchannel is strong enough.

Pairing Methods in LE Secure Connections

Just Works

At first devices exchange their public keys, thenthe peripheral will generate a random seed value tocalculate his confirmation value "Cb". It sends the"Cb" with the random number to the master. At the

same time, the master generates another randomvalue and sends it to the peripheral and creates itsown confirmation "Ca" value using the peripheral’srandom seed. If the confirmation codes match, thecommunication continues.

Using ECDH key exchange, the Just Works pairingmethod in LE Secure Connections becomes resilientto passive eavesdropping compared to the samemethod in LE Legacy Connections. However, it isstill vulnerable to MITM attacks as there is no way toverify the identity of the connected devices.

Passkey

In this method, the two devices exchange theirpublic keys and a 128 bit random seed to authenticatethe connection. Then the 6 digit passkey is processedbit by bit. Each device will compute his confirmationvalue for one bit of the passkey and reveal it to theother device. If the confirmation codes match theprocess continues, otherwise communications stop.

Due to this process, the passkey method for LESecure Connections is much more resilient to MITMattacks than it is in case of LE Legacy connections.

Out of Band (OOB) pairing

In OOB pairing the process is similar, except thatthe public keys, randoms and confirmation valuesare all exchanged via a different wireless technology.As in LE Legacy connections, OOB pairing providesprotection from attacks only if the OOB channel issecure.

III. Attack Examples

There can be defined a series of attack vectors thata malicious device will try to use in order to exploit avulnerability:

• Passive interception• Denial of service• Package re-send• Active interception

Common targets are BLE devices that use the"Just Works" pairing methods, as they are moresusceptible to these attacks. Also, devices that usethe "Static Passkey" pairing method are vulnerable aswell, because the passkey is only a six digit number,

5


Figure 2: Sniff a write request

hence it is not a problem to brute-force it and pairwith the device.

In our laboratory we aimed to reproduce eachattack and investigate what vulnerability they exploit.In order to do so, we used the following hardware:

• Nordic Thingy:52 [6] - which will play the roleof the BLE peripheral, the target device for theattack.

• Nordic nRF52840-DK 3 - which will be used as asniffer and observer.

• Raspberry Pi 3 B+ (RPi) 4 - we used two devicesas we required two different BLE modules toperform a MITM attack.

• Android Phone (Huawei P10Lite) with NordicThingy App 5 installed - which will be our userand targeted victim.

As for software, we used :

• Gattacker [7] - an open-source tool written inNode.js that allows to perform a series of attacks(Denial of service, Replay, MITM, etc.) on BLEdevices.

• BTLE Juice [8] - complete open-source frameworkto perform Man-in-the-Middle attacks onBluetooth Smart devices.

• Nordic nRF Sniffer v2.2 6 - firmware tool usedfor sniffing (Nordic nRF52840-DK).

Passive Interception

As harmless as it may sound, Passive Interceptionor Eavesdropping is the easiest way for an attacker toextract sensitive information. For example, a smartlock that does not use encryption and notifies atconnection its current access code [9] will be prettyeasy to unlock. Another case could be a "Smartfinder", "Smart Beacon" or an "OTP authenticationtoken" [10]. Of course, these situations are rare, andusually, passive interception is used by an attacker toresearch the communication protocol, sniff the keyexchange and generally prepare for a more complexattack.

By using our sniffer (Nordic nRF52840-DK) we cansniff all the communication between the peripheral(Nordic Thingy:52) and the master device (Phone).[Figure 2]

Denial of service

The denial of service attack has two possibleapproaches: impersonate the peripheral device or themaster [11]. This attack will disturb the availability

3. https://www.nordicsemi.com/Software-and-tools/Development-Kits/nRF52840-DK

4. https://www.raspberrypi.org/products/raspberry-pi-3-model-b-plus/

5. https://play.google.com/store/apps/details?id=no.nordicsemi.android.nrfthingy

6. https://infocenter.nordicsemi.com/pdf/nRF_Sniffer_UG_ v2.2.pdf

6


(a) RaspberryPi advertising as Thingy (b) Mobile app feedback

Figure 3: Dos Attack

of the BLE device, which in some cases can beconsidered as a critical vulnerability (medical devices,smart locks, sensors). Of course, RF DoS attackis not new and can be performed using a genericRF jamming device as well. However, Bluetooth LEis designed to be robust against interference and itrequires a great amount of knowledge and precisionto perform such an attack. Yet, using the upperlayers of BLE stack, it becomes much easier to denya peripheral service by impersonating it and trickingthe user.

Using Gattacker, we cloned our peripheralsMAC Address and its advertisement package so aRaspberry Pi will advertise with the same data andsame address as the peripheral. To assure that theuser will connect to the RPi instead of peripheral, theRPi will advertise as fast as possible (every 10ms). Asall peripherals are usually in Low-energy state, theywill advertise with a lower frequency (once or twiceevery second) which will give the attacker a greatadvantage.

In our case, the Nordic Thingy:52 sends anadvertise package every 640ms, where RaspberryPi sends the same package every 10ms [Figure 3]. Asboth devices are positioned at same distance from thevictim and both having same package loss rate (1-2%,due to different radio interference) it will leave theuser with the chance of 98.43% to connect to the"false" peripheral.

In a real life scenario this theoretical chance willbe significantly lower as the attacker will probablybe positioned at a greater distance. Due to theradio interference the package loss will be greater.However, even in this case, the attacker can performa DoS attack with a 67% probability [11].

However, if the peripheral device is not capableof multiple connections, the attacker will choose toconnect to the peripheral instead as a "false" master,

Figure 4: MITM diagram

thus ensuring 100% chance of success for attack.

Active Interception and Replay attack

Active Interception and Replay attack commonlyknown as "Man in the Middle" (MITM), is possiblewhen an attacker invokes connection with theperipheral and the master device, and passes themessages between them. The devices are tricked intobelieving that they are communicating directly to oneanother, while in fact the transmission is controlledby a malicious device.

The attacker’s device will "clone" the targetedperipheral and will connect to it with a "false" masterdevice. At the same time, it will start advertisingthe "cloned" peripheral, faster than the original, asdescribed above in DoS attack, to ensure that thevictim will connect to the "cloned" device. Once theconnection is established, the attacker will relay themessages from the victim to the peripheral and back

7


(a) Replace name with "Hacked" (b) Mobile app feedback

Figure 5: MITM Attack

[Figure 4]. At this point the attacker can wiretap,alter or inject data into the transmission.

The ability to manipulate and inject data can resultin various attack possibilities.

Data Manipulation

For a proof of concept, we managed to trick ourNordic Thingy mobile app that the temperatureregistered by the Thingy:52 is 0 degree. Usingthe BTLE Juice tool we captured and modified thetemperature that the peripheral was transmitting.[Figure 5]

Another possible scenario could be the following- a Point of Sale device is connected to a mobileapplication. As sensitive data are properly encrypted,it is not possible to steal credit card data, howeverthe device allows a few unprotected services, suchas "display message". In this case we can modify thedisplayed message at our will (for example showing"Transaction Failed" when it was a success or viceversa). [10].

Replay

During the challenge-response authenticationprocess, every time the mobile application calculatedthe same session encryption key in response to agiven challenge value. At first, the evildoer couldsniff the challenge-response authentication processand the encrypted communication. Next, during theauthentication, by impersonating the original device,the attacker could serve to the mobile applicationa previously recorded challenge value. Now, the

application would calculate the session encryptionkey matching the sniffed one. After this, theattacker could replay the recorded encrypted deviceresponses, and the mobile application would properlydecrypt them using the same key.

As another example consider a smart lock that usesencryption, but without any mechanism to protectfrom the replay attack. An intruder, using thismethod can mislead the user, who invokes the "latch"command. The user will leave the premises convincedthat he locked the door, where in fact the commandwas not delivered to the actual device.

IV. Attack Limitations

After presenting the tools and techniques used byan attacker against BLE devices, it is important tounderline also their limitations..

Physical Range

Due to the fact that BLE is a short range wirelessprotocol, physical range becomes an important issue.Most BLE devices have a working range between 10and 30 meters, forcing the attacker to be in proximityto the device.

Single Target

An intruder will usually try to attack a single targetand be as swift as possible. He will prepare for theattack and at the right time will execute it. Typically,

8


he will be equipped with one device, however it mighthappen to attack a device multiple times at once.

Advertising Latency

One of the most important things is the attacker’sneed to advertise the "cloned" device as fast aspossible (in case of DoS attack or MITM), becausehe must be certain that the victim will connect to hisdevice instead of the original.

V. Detection and Protection

The primary goal of this paper is to present both adetection and protection solution. As presented in thechapters above, there are a variety of possible attacks,each one of them exploiting a different vulnerabilityof a Smart Bluetooth device. Usually researchersoffer a set of advice for vendors and most of the timethey are not taken into consideration.

Therefore, our approach is to present a technologythat can detect a number of attacks and even preventthem. Based on the limitations of possible attacks wedesigned a defensive technology that can save BLEdevice users against unwanted attacks.

As everything from the Link Layer (LL) up tothe Application Layer (APP) can be "cloned" andreproduced with high fidelity by an attacker, our focusstayed on the Physical Layer (PHY). By analyzing theRSSI value of a peripheral device, we came up with aseries of heuristics that allowed us to detect in realtime the presented attacks.

Detection

The naive way to detect that you are not connectedto the right device is to verify it’s MAC Address,advertising data and services. Unfortunately, acorrect attack will emulate all three of them perfectly,leaving you guessing if you are connected to yourdevice or not.

Looking for a dramatic change in the RSSI valueis one way to tell that something is wrong. It is notaccurate because you can get different readings everytime you change a device’s position. Also the RSSIvalue may change depending on battery level of theperipheral. Even so, if you detect a sudden change ofRSSI value in several consecutive packages, without

moving the master or the peripheral, you may becertain that you have connected to a different device.

More important is to determine the advertisingfrequency of the device, in other words, how manyadvertising messages does the peripheral send persecond. All of the BLE devices on the market,targeted for production and not for development,have a fixed advertise delta-time. These devices canonly enable or disable their advertisement. Somedevices may have more well defined distinct advertisedelta-time values, for example:

• for regular use• for pairing window

During the pairing window devices will usuallyadvertise faster than normal to ensure a fasterconnection. For example, a smart lock will advertisea package once a second, but when put in pairingmode, it will advertise 5 times faster (every 200ms).Another important thing is that a BLE peripheralwill never advertise as fast as possible because itis power consuming and defeats the Low Energypurpose. As long as you know the advertise delta-time(or each of them if there are several), you can detecta MITM attack (or even a DoS attack), as it requiresto advertise as fast as possible to ensure its success.The attacker’s advertise delta-time will always besignificantly lower.

Passive interception is one of the attacks thatcannot be detected. If a BLE device will communicatesensitive data unencrypted, there is nothing one cando to prevent an attacker from sniffing it (unlesspowering it off and never using the device).

Advertising period

In order to determine a BLE device advertisedelta-time we designed an algorithm that willapproximate this time period with the precision of+/-10ms [Algorithm 1]. The algorithm scans a numberof advertisements and returns the device’s advertisedelta-time. Experiments have shown the followingconclusions:

• 15 packages are enough to calculate theadvertise frequency

• if the average RSSI value is lower than -65db, itwill have better precision if 10 more packagesare scanned

9


Figure 6: Sniff a write request

Algorithm 1: Calculating a BLE deviceadvertise frequency

1 function calc_adv_freq(device) ;Input :Advertise packets containing RSSI

valueOutput :Advertise delta-time

2 rssiArr = [];3 while True do4 rssi = device.scanAdv().getRssi();5 rssiArr.push(round(rssi/10) ∗ 10);6 if SUM(rssiArr)/rssiArr.len >= −65 AND

rssiArr.len >= 15 then7 dT = GCD(rssiArr);8 return dT;

9 end10 if SUM(rssiArr)/rssiArr.len < −65 AND

rssiArr.len >= 25 then11 dT = GCD(rssiAr);12 return dT;

13 end

14 end

• because of radio interference and the qualityof the antenna advertisements will arrive atdifferent times, but close to real value. Forexample, if the Thingy:52 advertises every640ms, the scans will show values like 638ms,639ms, 642ms, etc. That’s why it is better to usea small approximation of the value (multiple of10).

• if due to interference some packages arrivecorrupted and are discarded, then the nextadvertisement packages will arrive after integermultiples of this time period.

Usually it will take no more than 1 minute to findout the advertise delta-time of the device.

Protection

For a proof of concept, we performed a MITMattack on our setup (Thingy:52 as peripheral andMobile phone as master) using two Raspberry Piboards and implemented a detection and protectionmechanism on another RPi [Figure 6]. At first we run

10


Figure 7: Scanning the peripheral

a script on our RPi that will scan the peripheral andcalculate its advertise delta-time. Once the delta-timeis determined, the RPi will enter in "observer mode"and will just scan the peripheral advertisement.[Figure 7]

Now, during the MITM attack when the RPi startsadvertising with "cloned" data, our "observer" willinstantly detect the difference and will be able tonotify that an attack is happening.[Figure 8 andFigure 9]

In addition to the notification, the "observer" cantrick the attacker and connect to the malicious devicehimself as a "fake" user. An attacker will not checkthe authenticity of the master device that initiatesa connection and will accept it, assuming that onlya real user will connect to the peripheral. Once theconnection between the "observer" and the maliciousdevice is established, the observer will just keepit alive, hence performing a DoS attack on theattacker’s device.

If the attacker retries his attempt, our "observer"will be ready to block it again. Depending on theantenna capabilities, the "observer" can connect tomultiple devices. For example, our Raspberry Pican disable 3 attacks at once, as it is capable ofmaintaining 3 different connections at the same time.

In case the peripheral device does not supportmultiple connections, the observer still protects theuser from sharing possible sensitive data and also

Figure 8: Detecting a MITM attack and connecting to theattacker

notifies the user about the unsafe peripheral.

VI. Conclusions and Future work

This paper presents a general view over the mostcommon attacks on BLE, describing each angle ofattack on the exposed vulnerabilities and the imposedlimitations.

Of course, in an ideal world, all BLE deviceswould use the most secure pairing methods, witha strong stack implementation, filtering all incomingconnections. Unfortunately, in the real world this isnot possible, as not every device is equipped witha keyboard and a display and don’t have unlimitedpower supply. Lots of BLE devices are still vulnerable,even though a series of papers describing BLEweaknesses were published in the last few years.This is mainly because there are devices that are notcapable of defending themselves. We would like tointroduce this novel idea of a protection technologythat can act as a shield against some of the mostknown BLE attacks.

This is just the beginning, as there are a lot morethings to cover. Our future work will consist inadding more heuristics. Our current interest lies inimproving advertise delta-time calculation algorithmand creating fingerprints which can uniquely identifyBLE devices.

11


Figure 9: Attacker advertising as peripheral and accepting a connection request

References

[1] J. O. Carles Gomez and J. Paradells, “Overviewand evaluation of bluetooth low energy:An emerging low-power wireless technology,”Sensors, vol. ISSN 1424-8220, August 2012.

[2] J. K. N. Matti Siekkinen, Markus Hiienkari, “Howlow energy is bluetooth low energy?comparativemeasurements with zigbee/802.15.4,” WCNC2012 Workshop on Internet of Things EnablingTechnologies, June 2012.

[3] Dialog Semiconductor, Bluetooth LowEnergy Chipset. Available at https://www.dialog-semiconductor.com/sites/default/files/da14580_fs_3v4.pdf.

[4] “Gatt protocol.”

[5] “Bluetooth specifications.” Available at https://www.bluetooth.com/specifications/assigned-numbers/service-discovery/.

[6] Nordic Semiconductor, NordicThingy:52. Available at https://www.nordicsemi.com/eng/Products/Nordic-Thingy-52, Documentation:https://nordicsemiconductor.github.io/Nordic-Thingy52-FW/documentation/.

[7] “Gattacker.” Available at http://gattack.io.

[8] “Btlejuice.” Available at https://github.com/DigitalSecurity/btlejuice.

[9] S. Jasek, ed., Blue picking – hacking, BluetoothSmart Locks, HackInTheBox, Amsterdam,2017. Available at https://conference.hitb.org/hitbsecconf2017ams/materials/D2T3%20-%20Slawomir%20Jasek%20-%20Blue%

20Picking%20-%20Hacking%20Bluetooth%20Smart%20Locks.pdf.

[10] S. Jasek, “Gattack whitepaper.” Available athttp://gattack.io/whitepaper.pdf.

[11] P. Gullberg, “Denial of service attack onbluetooth low energy,” September 2016. DOI:10.13140/RG.2.2.12059.26407.

12

https://www.dialog-semiconductor.com/sites/default/files/da14580_fs_3v4.pdfhttps://www.dialog-semiconductor.com/sites/default/files/da14580_fs_3v4.pdfhttps://www.dialog-semiconductor.com/sites/default/files/da14580_fs_3v4.pdfhttps://www.bluetooth.com/specifications/assigned-numbers/service-discovery/https://www.bluetooth.com/specifications/assigned-numbers/service-discovery/https://www.bluetooth.com/specifications/assigned-numbers/service-discovery/https://www.nordicsemi.com/eng/ Products/Nordic-Thingy-52https://www.nordicsemi.com/eng/ Products/Nordic-Thingy-52https://www.nordicsemi.com/eng/ Products/Nordic-Thingy-52https://nordicsemiconductor.github.io /Nordic-Thingy52-FW/documentation/https://nordicsemiconductor.github.io /Nordic-Thingy52-FW/documentation/http://gattack.iohttps://github.com/DigitalSecurity/btlejuicehttps://github.com/DigitalSecurity/btlejuicehttps://conference.hitb.org/hitbsecconf2017ams/materials/D2T3%20-%20Slawomir%20Jasek%20-%20Blue%20Picking%20-%20Hacking%20Bluetooth%20Smart%20Locks.pdfhttps://conference.hitb.org/hitbsecconf2017ams/materials/D2T3%20-%20Slawomir%20Jasek%20-%20Blue%20Picking%20-%20Hacking%20Bluetooth%20Smart%20Locks.pdfhttps://conference.hitb.org/hitbsecconf2017ams/materials/D2T3%20-%20Slawomir%20Jasek%20-%20Blue%20Picking%20-%20Hacking%20Bluetooth%20Smart%20Locks.pdfhttps://conference.hitb.org/hitbsecconf2017ams/materials/D2T3%20-%20Slawomir%20Jasek%20-%20Blue%20Picking%20-%20Hacking%20Bluetooth%20Smart%20Locks.pdfhttps://conference.hitb.org/hitbsecconf2017ams/materials/D2T3%20-%20Slawomir%20Jasek%20-%20Blue%20Picking%20-%20Hacking%20Bluetooth%20Smart%20Locks.pdfhttp://gattack.io/whitepaper.pdf

IntroductionBLE Protocol DescriptionAttack ExamplesAttack LimitationsDetection and ProtectionConclusions and Future work

Documents

Detecting and preventing Bluetooth Low Energy Attacks...security establishment, and others. Addresses Bluetooth Low Energy devices use addresses to recognize each other. The BLE addresses