Recently, I’ve been doing a lot of reading about Bluetooth. I realised that despite using it to enable wireless connectivity on almost every device imaginable, I don’t know very much about what it is and how it works.
In 1994, a team of engineers at Ericsson were investigating ways of wirelessly unifying computers and mobile devices. They wanted a way to quickly and easily connect any given device to any other device. The protocol they created was eventually named Bluetooth, after an 11th century Viking king named Harald Blåtand (Anglicised as Bluetooth) who unified large parts of Scandinavia under his control.
In addition to Ericsson’s engineering team, Nokia and Intel were also working on the same problem. However, the engineers soon realised that forming a new technological specification for worldwide use was an enormous task. So in 1998, Ericsson founded the Bluetooth Special Interest Group (SIG) with Nokia, IBM, Intel and Toshiba. The first formalised specification for Bluetooth 1.0 was released a year later.
It was an engineer at Intel, Jim Kardach, who suggested the name Bluetooth:
I explained that Bluetooth was borrowed from the 10th century, second King of Denmark, King Harald Bluetooth; who was famous for uniting Scandinavia just as we intended to unite the PC and cellular industries with a short-range wireless link.
– Jim Kardach1
The IEEE has designated Bluetooth as standard 802.15.1, but the organisation no longer maintains the standard. The SIG now owns the Bluetooth specification and its standards and trademarks, licensing them to companies. As a result, the group has grown into a not-for-profit organisation with professional staff and support from over 30,000 member companies.
The Bluetooth 1.0 specification, launched in 1999, quickly led to Bluetooth-enabled chipsets, wireless mice, and even mobile phones within a year. Since then, there have been many more significant updates to the specification.
The Bluetooth 2.0 specification introduced an Enhanced Data Rate (EDR), allowing for faster data transfer between connected devices. This EDR has been improved upon and used by devices requiring constant data communication, such as audio streaming to headphones. Version 3.0 introduced High Speed (HS) transfers over 802.11 (Wi-Fi) using Bluetooth, allowing for much higher speeds than EDR alone.
One of the most significant changes to the specification came in version 4.0, which introduced Bluetooth Low Energy (BLE). Low energy connections transmit data in short bursts using less power and see widespread use in IoT and wearable devices such as fitness trackers.
In 2016 the SIG released the Bluetooth 5.0 specification, which made significant improvements to the BLE standard. The release introduced the ability for BLE use on audio devices, reducing the battery and power use for wireless headphones, which previously were only able to use Bluetooth classic. Additionally, the specification introduced the Bluetooth mesh network, a many-to-many network of BLE connected devices.
Bluetooth is a short-range wireless communication protocol operating via radio transmissions in the 2.4GHz frequency band. It can be considered a smaller-sibling to Wi-Fi, acting as a Personal Area Network (PAN) rather than a Wireless Local Area Network (WLAN).
As with all wireless communication, Bluetooth requires both a transmitter and receiver to send and receive radio signals. These functions are typically integrated into a single System on Chip (SoC) to integrate into a device; this SoC also includes a control processor required to handle signal modulation. On complicated or size restricted devices, such as smartphones, other wireless technologies such as Wi-Fi operate on the same chip.
The typical range for Bluetooth devices is approximately 10 metres for class 2 & 3 devices and up to 100 metres for class 1 (primarily industrial) devices. Although these ranges vary because physical obstacles such as walls can reflect the signal and affect how far it can travel, sometimes positively but usually negatively.
There are currently two forms of Bluetooth, each with its range. Bluetooth Basic/Enhance Data Rate for short-range connections with continuous data transfer, such as headphones. Then there is BLE, designed for small bursts of data over a more extended range to conserve battery life; IoT sensors are an excellent example of BLE devices.
A Bluetooth profile is a set of pre-defined capabilities with an associated custom stack. These are designed for specific use cases to provide a basic set of functionality and allow more straightforward development for the Bluetooth operations required for the particular application. There are over 30 different profiles that are available to use. Some are common and used by all Bluetooth devices, such as the Generic Access Profile (GAP), which is the basis for other profiles and determines how two devices establish a Bluetooth connection. Then, other more specific profiles such as the Health Thermometer Profile (HTP) that facilitates protocols for exchanging medical device data.
These profiles are listed in the latest Bluetooth specification and allow for more as new application classes emerge over time.
A piconet is a small network that is created and used by Bluetooth for communication. The most straightforward configuration is a point-to-point piconet with one master device and one slave device. The master initiates contact and tends to control the network timing.
A piconet can support one master and up to seven connected slaves in a point-to-multipoint configuration. A typical example of this is a smartphone (master) and multiple Bluetooth slaves such as headphones, speakers and another phone for file transfers. A more complex example can be where one device is a master in one network and a slave in another network. A configuration such as this which goes beyond the master-and-seven-slave setup, is known as a scatternet.
The initiation of a piconet handled by the master device is a process defined by the Bluetooth protocol specification:
- Inquiry - The master sends an inquiry request to determine devices in range
- Inquiry Response - In range devices respond with specific information (Paging parameters)
- Page - The master pages the device it wishes to connect to
- Page Response - The paged device acknowledges and responds
- Link Parameter Exchange - The devices exchange link parameters, and bi-directional data transfer can begin
In the United States, the FCC regulates the product certification, modulation requirements and transmission power of devices operating in the 2.4GHz frequency band. Many other countries also have similar restrictions on power levels, modulation settings and other technical specifications of electrical equipment.
Any digital signal is composed of binary data transmitted through a wire and detected by any voltage-sensitive device in the circuit. This data is known as the baseband signal and is bundled into a wireless Radio Frequency (RF) carrier wave, then transmitted wirelessly by a radio. There are a few ways to do this:
- AM and FM analogue radio signals
- Phase Shift Modulation
Modulation is the process of putting information into a carrier RF wave and extracting it is demodulation. Modulating a signal is known as keying, and there are several different keying schemes to do this, such as Frequency Shift Keying (FSK) or Phase Shift Keying (PSK). Typically, the various keying schemes are related to the hardware requirements and error rate at a particular power level.
The Bluetooth specification uses both FSK and PSK schemes for data modulation. FSK was chosen for the lower power and hardware requirements than PSK, though PSK has a better Signal-to-noise ratio (SNR). To improve the SNR, the SIG adapted FSK to include Gaussian Baseband Filtering, a process that filters specific frequencies to smooth out the modulation process’ power transitions, thereby creating the Gaussian Frequency Shift Keying (GFSK) as the specified modulation scheme.
Newer versions of Bluetooth use two different modulation schemes, Basic data rate uses GFSK, and enhanced data rate uses Differential Phase Shift Keying (DPSK), an improved version of PSK.
The other core RF technique integral to Bluetooth is Frequency Hopping. The 2.4GHz band extends from 2.4GHz to 2.483GHz, providing 79 channels of 1MHz bandwidth to utilise. The process of frequency hopping means continually changing channels while transmitting a stream of data, and it helps to mitigate interference in the crowded 2.4GHz band. The Bluetooth specification defines the hopping rates, timing synchronisation and other protocols.
Different objects, surfaces and even internal device components can cause signal reflection of radio waves, leading to a multipath propagation problem at the receiver. This problem occurs when the same wave is reflected differently by different obstacles in the environment, causing it to arrive at the target multiple times from multiple different reflected paths, confusing the receiver.
These reflected signals can also be stronger upon reaching the Bluetooth device, for example, travelling down a long, narrow corridor, causing the signal amplification. However, it is more likely to become a source of interference or signal loss due to the additional time taken to arrive.
Another source of interference is from other devices/protocols operating on the 2.4GHz frequency band, such as Wi-Fi or microwave ovens. Keeping a distance of two meters between a Bluetooth transmitter and a Wi-Fi node can reduce interference to reasonable levels.
The core strategy to passively mitigate interference is to use channel hopping. If a device encounters narrowband interference on a given channel, the next hop should solve the problem. The hops of Bluetooth and Wi-Fi are not synchronised, so it is improbable that they would both make the hop on the same channel simultaneously.
Actively mitigating interference can be done collaboratively between devices or non-collaboratively. The collaborative approach is common in smartphones, which usually house all sources of RF radiation (Wi-Fi, Cellular, Bluetooth) on the same SoC. This chip can then manage each radio to operate without interference from one another. The master-slave connections have synchronised channel-hops and timings within a piconet, reducing the likelihood of mistakenly accepting incorrect packets, but the interference is still there.
Non-collaborative strategies include rejecting signals below a certain threshold, as determined by the first packet that established the signal and link.
The Bluetooth stack is a set of protocols operating together to handle the data required for a Bluetooth session. The protocols are divided into the lower controller stack and the upper host stack.
The Bluetooth Low Energy protocol stack
The host stack contains protocols to handle higher-level functionality, such as service discovery or passing data packets to the Host Controller Interface (HCI) to go to the controller stack. It also contains Bluetooth profiles as well as an API for applications. Given the high-level implementation of the host stack, it often sits at the device’s operating system level; however, smaller devices, such as wireless headphones, may not have an OS and run a simplified host stack.
The controller stack contains the protocols responsible for establishing and controlling connections between devices. These protocols are primarily implemented on the Bluetooth hardware and handle the initiation and management of a Bluetooth connection, data transfer between devices and the HCI itself for communication between the host and controller stacks.
Bluetooth relies upon three distinct features for ensuring a secure connection:
These three steps are each involved in establishing a secure Bluetooth connection. Firstly the two devices must authenticate each other; this is a process to ascertain who’s who for each of the connecting devices. The authorisation process is to establish trust and permissions for a connection, such as whether device X is allowed to connect to service Y. Finally, after negotiating a key, the connection is encrypted between the two devices.
These processes operate across the Bluetooth stack, meaning they offer cross-layer functionality. In theory, these processes should offer secure connections; however, in practice, there have often been concerns about the pairing and authentication procedures, leading to updates with each revision to the specification.
During this process, some acknowledgement from the user before establishing a connection may have to occur. The threat here is authenticating the device and not the user, meaning anyone in control of the device can create a trusted connection.
The first step of security begins with a potential master device defining how to discover it and its options for connectivity.
- Silent - Makes the device undetectable, and it doesn’t accept connections, though it can detect traffic. Can’t enter PAGE SCAN or INQUIRY SCAN states.
- Private - The device can enter PAGE SCAN but not INQUIRY SCAN, making the device undiscoverable.
- Public - The device can enter both PAGE SCAN and INQUIRY SCAN modes and can therefore be discovered and is implicitly open to connections.
There are three different security modes defined in the Generic Access Profile and the other connection modes.
- Mode 1 (Non-secure) - This is Bluetooth communication between devices without authentication or encryption of the data.
- Mode 2 (Service level enforced security) - This mode enables a secure connection after establishing the initial connection request and links. However, this connection phase does not protect anything until it finishes.
- Mode 3 (Link level enforced security) - Allows security procedures to be initialised while the connection is establishing.
Bluetooth Security Vulnerabilities
Given the local proximity requirements of a Bluetooth connection, an attacker must also be nearby to interact with their target. One potential threat is that of an attacker passively listening to Bluetooth traffic and attempting to discover two devices negotiating a connection, steal the encryption key and then connect to both devices to pose as each other (a Bluetooth example of a Man-in-the-Middle attack).
Over the years, security researchers have discovered issues with various parts of the Bluetooth specification, such as key negotiation as part of the pairing and authentication process. These issues disclosed by researchers help to improve security by leading to fixes.
Although there are strategies to mitigate different Bluetooth security risks, it is often up to the manufacturer to implement these, typically at the hardware or firmware level. Therefore it is necessary to consider whether a manufacturer complies with the most up-to-date security recommendations.
The Future of Bluetooth
Since the introduction of Bluetooth Low Energy in the 4.0 specification, each new update has focused on it far more than Bluetooth classic. The release of the Bluetooth 5.0 specification introduced the Bluetooth Mesh network, an ad-hoc network of BLE connected devices. This network appears to be a way to provide services for connected smart devices in the future, which given the increase of IoT devices in both the home and workplace, looks to be something with which we will all become very familiar in the coming years.
The 5.0 and later 5.1 specifications have updated the BLE spec to support wireless headsets for audio transmission in addition to the mesh network. Previously, wireless headphones had to use Bluetooth classic to transmit continuous audio data; however, they can now take advantage of the BLE standard to save power.
Finally, and possibly the best improvement is simply to the range and speed of BLE itself; Bluetooth 5 has four times the range, twice the transmission speed, and eight times the broadcasting message capacity of the previous version.
The SIG sees Bluetooth Low Energy as the future of the protocol, continually working to improve it over Bluetooth classic. This focus is not a surprise given the ever-increasing number of intelligent devices sold worldwide as part of the Internet of Things. It will be interesting to see where the protocol goes with Bluetooth 6 due for release sometime in the next few years.