Introduction

This blog is about Bluetooth Low Energy (BLE), which is the relatively new, lower-power version of the Bluetooth protocol. BLE was introduced in version 4.0 of the Bluetooth Core Specification, which was released in June 2010. The idea behind it was to redesign the Bluetooth protocol for low power consumption and cost, for use in a new set of applications. Crucially, BLE is not compatible with traditional Bluetooth, although the specification does allow for devices to implement either or both of the protocols. As we’ll show, the changes made to BLE allow it to work in a very different manner to traditional Bluetooth.

It’s a technology that piqued the interest of our Research team, purely because of one interesting application: iBeacons. That initial spark has resulted in a few different strands of work, all of which are covered here.

In the beginning – iBeacons

All of this started when Paul in our Research team read about iBeacons online, and bought two cheap ones on Amazon. After a while he brought them into the office for us to play with. An iBeacon is a BLE device with one function: to constantly broadcast BLE packets containing just a serial number that uniquely identifies the iBeacon.

As the name suggests, iBeacons are an Apple protocol, and many of the early applications are very iOS-centric.Using BLE means that they can run from a coin-cell battery for a couple of years, something that wouldn't have been possible with traditional Bluetooth.

To make use of an iBeacon, you typically need a mobile application that looks for them, and knows what to do when it finds them. In the UK, both BA and Virgin have added iBeacons into their airport lounges, so the phone application that is already used to show a boarding card can detect when you walk into the lounge, and tell you the Wi-Fi password for that day.

A number of companies and organisations are already using or experimenting with iBeacons, for example Major League Baseball, Apple themselves, House of Fraser, Regent Street (the BBC have a video) and Waitrose.

Whilst location-based services aren’t new, using BLE means that location-aware applications can work simply by receiving BLE packets, which have a longer range than RFID, and don’t consume as much power to scan for as Wi-Fi or GPS.

Google introduced a similar mechanism in Android 5.0, with Android Trusted Places and Trusted Devices. This allows your Android device to automatically unlock when it’s in a trusted place, or when it is in range of a trusted device, such as a Bluetooth device.

Another novel BLE application is Google Physical Web, their iBeacon-like specification to push out a URL via BLE packets. Implementing an URIBeacon, as they are called, is straightforward. This is particularly true if you make use of ARM’s mbed framework, which has sample code for many BLE applications, including URIBeacons. A free mbed account lets you write and compile code from the mbed web interface.

Thankfully many of the initial applications of iBeacons require you to be using a specific application already. One of the first questions on the Google Physical Web introduction is “will you be pestering people with alarms?” Encouragingly, they say that “a core principle of this system is no proactive notifications” (their emphasis). It wouldn't be too surprising, however, to see a handset manufacturer supplying devices with a pre-installed iBeacon app that allows its partners to push location-based adverts at people. You can at least turn off Bluetooth on your phone.

Whilst iBeacons were the first BLE technology we came across, there are a surprisingly large number of devices out there that are already using it.

Other applications

Later sections cover the work we've done to survey BLE devices already in use, some of which are surprising, but many that people would expect. One of the most topical applications for BLE is in wearable technology and fitness trackers, about which there is a lot being written. Being small and low powered and requiring regular updates, BLE is an obviously suitable protocol for them to use.

Whilst many people are aware of fitness trackers (e.g. Fitbit, Jawbone) and heart rate monitors, and Bluetooth headsets aren't new, not many people would guess at combining the two to produce headphones that measure your pulse from inside your ear like the Jabra Pulse does.

The Apple Watch presumably supports it, but we can’t tell from the technical specifications as they only state that it supports Bluetooth 4.0, which includes BLE but also traditional Bluetooth.

And finally, if you’re looking to “enrich your sleep experience”, there’s always the Withings Aura .

Before we cover the work we've done on BLE, it’s worth taking a look at some of the important aspects of the technology.

The technology and why it matters

History

We’re currently on version 4.2 of the Bluetooth Core Specification, which means there have been two point releases since BLE was first introduced. Interestingly the recent amendments seem to be backtracking on some of the original design principals of BLE: to implement light-weight encryption and keep packet sizes down. In fact they are entirely contrary, as they introduce longer packet lengths for increased data rates, and Diffie-Hellman key exchanges.

A point on nomenclature: devices labelled as “Bluetooth Smart” support BLE, and those labelled as “Bluetooth Smart Ready” support both traditional Bluetooth and BLE.

Spectrum

BLE runs on 2.4GHz, the same radio spectrum as Wi-Fi, regular Bluetooth and the ISM band. As we've written recently, this is a very congested section of the spectrum.

BLE’s power output is only 10mw (10dBm), a tenth of the power of 802.11 Wi-Fi (100mw/20dBm) but it is able to co-exist (most of the time) in the spectrum with its more powerful neighbours through a variant of Bluetooth’s Frequency Hopping Spread Spectrum (FHSS) modulation. At that power, the range is restricted to less than 100m in an open area.

The BLE spectrum is divided into 37 data channels and 3 advertising channels. Established BLE connections hop across the data channels according to the channel map, which is agreed in the handshake protocol.

Advertising packets

Crucial to the operation of BLE, and important to following sections of this blog, is the fact that most BLE devices constantly broadcast indirect advertising packets in order to advertise their presence. These packets are broadcast across the three advertising channels, and the first step of connecting two BLE devices is for one to respond to the other’s advertising packets.

Sometimes the advertising packets contain the device name, which may be unique such as the “Garmin Vivosmart #12345678” or the Samsung "GALAXY Gear (1234)", or are even user-chosen such as “Jules' Watch”. The advertising packets contain fields for manufacturer-specific data, including universally-unique IDs (UUIDs) for different services. Some of these UUIDs start with a manufacturer ID. For example, Fitbit Charge HR fitness trackers all send the UUID "adabfb00-6e7d-4601-bda2-bffaa68956ba".

Many of these fields can be used to identify a product from a particular manufacturer, a particular model of product, and sometimes a particular device, which negates the effort made to disguise devices by randomising the MAC address.

Identifying devices

Like other network protocols, BLE relies on identifying devices by their MAC addresses. As they broadcast advertising packets constantly, any tool that logs BLE packets could be used to track a specific device. This issue is addressed in a blog from the Bluetooth SIG.

All BLE devices must have at least one public address or random address. Random addresses can be either a static address that is fixed for a power cycle, or a private address that is only resolvable with a shared key. The above blog says that random addresses mean that an attacker “…would not be able to determine that the series of different, randomly generated MAC addresses received from your device actually relates to the same physical device”.

Contrary to the intentions of the SIG, most of the devices we've seen have a random MAC address, in that it’s not possible to identify the vendor from the beginning of the address, but it’s still fixed. A test Fitbit has had the same MAC address since we started this work, even though it’s completely run out of battery once. Some manufacturers have gone with public addresses that use their OUI, for example all the devices from Nike and MI that we've seen have Nike or MI MAC addresses (starting with 9C:A1:34 and 88:0F:10 respectively).

We've seen some devices that are clearly changing their MAC address for successive advertising packets. They are sometimes easy to identify as they have a counter that increments the last few bytes of the address, and often send out constant identifying information.

Authentication and encryption

Like regular Bluetooth, BLE supports a number of different schemes for pairing two devices. Version 4.2 of the specification introduced Secure Connections, which supports Elliptic Curve Diffie-Hellman for key exchange. Prior to 4.2, devices can choose between Just Works, Passkey Entry and Out of Band. Just Works is effectively no authentication, which at first seems like a terrible idea, but how do you authenticate to a device that doesn't have a screen or any input mechanism? If we care about security and privacy, we have to trust that the manufacturer has implemented their own.

The main purpose of pairing is to exchange encryption keys and set-up parameters. BLE does support encryption implemented in the protocol specification, but it is not always used in products that we've seen. Some vendors seem to have chosen to implement their own encryption of the underlying data, rather than rely on BLE security.

Mike Ryan’s work has shown that if you can capture the initial handshake, breaking some of the authentication schemes to recover the encryption key is not too hard, nor is figuring out the channel-hopping map. The likelihood of capturing the handshake is rare, as you typically only have to pair devices once.

Support in mobile phones

BLE has been supported by the major phone operating systems for some time now, for example since iOS v5, and Android 4.3.

Privacy

Most of these devices, in their normal operation, broadcast constantly. The range is supposed to be around 100m in an open area, but as mentioned in the above previous research (albeit for regular Bluetooth), and from what we've seen in surveying for devices, devices can be detected at a greater range, probably due to anomalies affecting RF propagation such as ducting. As mentioned about, the random MAC addresses are still largely fixed.

Whilst it was done for traditional Bluetooth, the “Bluesniping” work showed that with a high-gain (e.g. 19dBi), directional antenna it was possible to pick up regular Bluetooth packets at distances of half a mile. The same principle would work for BLE and the potential intercept range can be calculated using a free space loss model with losses to represent window panes and walls.

If I have an easy way to scan for these devices, and can attribute a device to a particular person such as a celebrity, your CEO or the police officer leading an investigation against your company, then I can easily tell when they’re nearby. Many of the available fitness trackers are waterproof and measure your sleep sleep, so there’s no need to ever take them off. Some stories are already starting to appear about organisations with concerns about wearable devices, for example the Chinese military.

Much has been written lately about the positive and negative effects or wearable technology and the “quantified self” (for example here and here). What is obvious is that many of these devices contain very personal information about someone's health and patterns of life, which can lead to amusing measurements, but also represent a wealth of data about an individual. Whilst many people are very happy to publish such information to social media others would be very protective of it.

Much like our previous work on IoT devices, it does seem like many manufacturers of wearable technology are keen to get their products to market as quickly as possible, with security sometimes tacked on as an afterthought. As far as fitness trackers are concerned, there has already been some good work on reverse engineering the protocol used by the Nike Fuelband.

Scanning for BLE devices on a laptop

The first thing we wanted to do was to scan for devices, and have a look at the traffic. Two of the common BLE System-on-Chip products out there are the Texas Instruments CC2540, and the Nordic Semiconductors NRF51. We went for the latter, which is available on the £30 development dongle, which comes with a free sniffing application, and has APIs to develop applications in C# and Python. For £50 Nordic also produces a development kit that can accept Arduino Uno compatible shields, and can run off battery power.

Both the dongle and development kit feature Segger chips that make them appear as USB mass storage devices, so you can program them simply by copying the compiled code onto the drive, and rebooting it. Compared to developing for embedded devices that require extra hardware programmers and debuggers, this is very easy. This shows how the vendors of the chips, such as Nordic, are trying hard to help people quickly develop products and get them to market.

The free Nordic sniffer lists all of the devices it can see, and allows you to launch Wireshark to collect traffic from a specific device. It doesn't log the devices seen, or store any of the data that it collects. We wrote an application in C# that scans for advertising data, and sends out scan requests to identify devices. It’s a console application that logs all the devices it sees into a database, along with all of the data from the advertising packets and scan responses. When it closes the application does some analysis on the database, to summarise the identified devices, to look for different devices that send the same field values and to look for repeated devices.

We've used the scan data to improve how many devices the scanner identifies, based on unique service data or UUIDs. For example, the Garmin Vivosmart fitness trackers have a device name that contains what looks like a unique ID. TomTom’s smart watch has a name chosen by the user. Fitbit devices all transmit a services UUID that seems unique per range of models.

Survey results

The first thing to say is that there are a lot of devices out there. The Nordic dongle that we used for the survey has a short antenna-track on its PCB. Running from my desk on the fourth floor of an office on a averagely busy road on the Isle of Dogs, we were surprised at how many devices are out there, and not just amongst our geekier-than-average colleagues.

It was pretty much as we'd expect, with a couple of outliers. There's a wide selection of fitness trackers out there, primarily from Fitbit, Jawbone and Garmin. There are also a lot of heart-rate monitors, a few bicycle devices and the odd Galaxy Gear. We've seen all the devices mentioned in this blog at least once.

We also saw lots of iPhones (they have a field that begins with the Apple manufacturer ID), or possibly a few iPhones that change their MAC address and the data they send out very frequently. A small proportion of these advertising packets are for AirDrop, as we looked into the format of those packets.

Scanning for devices on a smart phone

Obviously the laptop isn’t entirely practical, so we also wanted an Android application to scan for devices. Some exist already (the Nordic one is pretty good), but we couldn’t find one that logs all the devices it sees, or tries to identify devices, or logs their location. So we decided to write our own.

Helpfully, Google published a sample application that scans for LE devices, and requests their GATT profiles. It’s not been updated to use the latest version of the Android API for Bluetooth LE, so we had to update. To make the application that we wanted, which is a decent proof-of-concept application for surveying devices, we added functionality to make it run as a background service, to store its data in a database, to log the logging of each device it sees, to export its database to the SD card, and to plot the location of the device on a Google Maps plugin. We even made an icon, although it did lead to lots of arguments.

Survey results

We looked for devices around our office, and on our commutes. A daily commute on the Central and Jubilee lines from Zone 4 to Canary Wharf detects around 100 devices.

To give you an idea as to how many of these devices are out there, half an hour near Canary Wharf station for lunch detected 149 devices. They included 26 Fitbits, 2 Jawbones, a couple of Nike products, one Estimote iBeacon (we're not sure where) and an Alcatel Pop C5, and a lot of iPhones.

Try for yourself

This application will be available here on the Google Play Store from Friday 22nd May. It works fine on our test phones (a Nexus 4 and a Sony Xperia Z3), but it’s very much a proof of concept. It requires the new BLE libraries from Android 5.0. 

Please let us know if you see anything interesting, or find any terrible bugs.

Conclusions

BLE is not a new technology, but it's adoption for certain applications is novel. Compared to traditional Bluetooth, it provides a new way for electronic devices to constantly communicate with each other. Whilst wearable technology and other applications are becoming increasingly popular, do many of the owners of these devices realise that they broadcast constantly?

These broadcasts can almost always be attributed to a unique device, contrary to measures taken in the protocol to anonymise devices by randomising the MAC addresses. Depending on the product, some of these broadcasts can also be identified to a particular manufacturer, or the product model, or an individual product.

Scanning for these broadcasts is easy either with cheap hardware or with a smartphone. This allows us to identify and locate particular devices, which for devices such as fitness trackers that are designed to be worn all the time, means that we can identify and locate a person, to within a limited range.

There are clear implications to privacy, just as there are ways that this technology could be exploited for social engineering and crime.

All of this is a work in progress - we'd like to do more on the Android application, and we're keen to write a battery-powered scanner to run from the development kit. We've had a look at the security of some of the wearable devices, and may well write a future blog on some of our findings.

Follow Up and Contact

Scott is a part of our Research team in our London office.