Background
Bluetooth is one of the most popular wireless protocols for devices. Maybe the biggest reason for the popularity is that Bluetooth technology allows direct connection to smartphones. Getting to this point hasn’t been easy. The Bluetooth specification has gone through many changes and end is relatively long . Compared to Wi-Fi, which is about 440 pages, the Bluetooth specification is over 3000 pages. That amount of complexity means that it’s more difficult to ensure implementations are secure, and more difficult for product developers.
To simplify and give flexibility, the Bluetooth device stack is divided into two parts – a high-level layer called the Host which manages application layer profiles and services, and a lower level controller that is runs the actual radio. This split was designed so that devices could have both or either part.
For example, some devices will contain a Host and a Controller together, while others split and the controller is one chip while the host is another device. They communicate using the aptly named Host Controller Interface (HCI), which defines a set of commands and events that allows the host to control the controller.
The controller, being essentially the radio (physical and link layer) usually runs its own in firmware close to the hardware, while the Host is implemented in a more power processor. For example, on Linux the BlueZ provides the Bluetooth host, and it communicates via HCI to the controller which is typically firmware implemented in a Broadcom, Qualcomm, or other chipset.
This allows updating the upper Host layer separately from the lower Controller layer. The controller is typically time critical – the processing of events from the radio have to happen in a timely fashion. Some devices combine the two and run them on the same processor if they can meet the timing requirements.
Over time, the Bluetooth specification has evolved from Bluetooth now called Classic to Bluetooth Low Energy. To understand how Bluetooth security got to where it was, let’s look
History of Bluetooth
Bluetooth itself has a long history. The origin of Bluetooth starts at Ericsson around 1989 when some of the lower level details of the protocol were defined, but it wasn’t until 1998 that the Bluetooth Special Interest Group (Bluetooth SIG, or the SIG as most people call it) came together.
Ericsson and IBM both contributed to the original standard, since neither was a market leader and they decided to open source the standard to drive mass adoption, an approach that has succeeded beyond their wildest dreams even though they’re not as involved as they were (most Bluetooth SIG members come from the usual suspects which are Bluetooth chip vendors or developers such as Apple, Google, Qualcomm, Broadcom, Intel, etc.).
The impetus for Bluetooth was connecting devices together. In the early days of computing, there was no way to wirelessly connect devices, as Wi-Fi would show up later. More critically, the connection between devices needed to be low power and efficient because mobile phones and headsets have small batteries.
Because of the goal of connecting different devices, the Bluetooth name was based on King Harald Bluetooth, a Danish king who united tribes into a single kingdom, in the way that the Bluetooth wireless protocol would unite devices. The Bluetooth logo is a rune merging Harald Bluetooth’s initial and has now become synonymous with wireless connectivity.
Developing Bluetooth Low Energy
The original Bluetooth protocol allows both audio and data to be transferred. Over the years, Bluetooth has been relegated primarily to audio and voice. Products like handsets, speakers and vehicles took advantage of it. Data transfer was possible but much less common for a few reasons.
The first is that to transfer some data quickly, Bluetooth took quite an effort to establish a connection. From a user experience perspective, this was not good enough. Bluetooth was also very complex and expensive to send small amounts of data, or operate from coin cell batteries. Billions of devices have been shipped with Bluetooth for audio.
MFI failing
Another big reason why Bluetooth data transfer failed to gain traction was because Apple iPhones, which are a huge part of the mobile phone market, required every device transferring data to join the Made For iPod (MFI) program. As part of this program, devices wanting to comply with MFI needed to add an authentication coprocessor chip, which added to the cost of devices and gave Apple significant control over device approval. On top of this, the first years of the MFI program were messy, with product developers having to navigate through Apple’s program to get a product out. Bluetooth data transfers never worked all that well even with non iOS devices.
Securing the vulnerabilities
In the early 2000’s, Bluetooth could be attacked to allow malware to be installed on phones. Bluetooth was very insecure, and that forced the Bluetooth SIG to really emphasize security (with mixed results at times). Bluesnarfing, Bluejacking, Bluebugging and other Blue attacks were prevalent.
Bluetooth Classic (or Bluetooth as it was called before Bluetooth 4.2) was developed through several specifications. Let’s look quickly at the version since they have an impact on the security history.
- Bluetooth 1.0/1.0B – The initial specification released in 1999 with some of the protocol basics
- Bluetooth 1.1 – Fixes to the specification
- Bluetooth 1.2 – Introduced Adaptive Frequency Hopping (AFH), higher transmissions, Extended Synchronous Connections (eSCO), 3-Wire HCI and added L2CAP flow control.
- Bluetooth 2.0 + EDR – One of the most significant Bluetooth specifications because it introduced Enhanced Data Rate of 2Mbps and 3Mbps. While EDR is technically an optional feature, it would become commonplace no radio would end up supporting just Basic Rate (BR).
- Bluetooth 2.1 – Bluetooth v2.1 represented the last major Bluetooth Classic specification change. While some changes were made later, many of which fixed issues, this specification added Secure Simple Pairing which sped up the pairing experience and helped security. Before the introduction of Bluetooth Low Energy, almost all devices would claim compliance to this version of the specification. Added support for Secure Simple Pairing and Security Mode 4
- Bluetooth 3.0 + HS – This specification added the ability to use an alternative MAC/PHY (referred to as AMP), meaning that while the initial connection establishment would be done over Bluetooth, the actual data transfer would be done over Wi-Fi. This specification was not widely used because it required Wi-Fi or another MAC/PHY (to my knowledge, no other MAC/PHY aside from Bluetooth was ever used).
Despite new releases of the Bluetooth Specifications, the Bluetooth Classic features are directly traced to Bluetooth v2.1 (with some fixes, most related to security in later specifications).
Building a new protocol – Low Energy
The shortcomings of Bluetooth led the Bluetooth SIG to develop and release Bluetooth Low Energy as part of the Bluetooth v4.0 specification. This is a new protocol that shares some commonalities with Bluetooth. Even though Bluetooth was already low energy compared to Wi-Fi and other protocols, it wasn’t enough. The idea was to enable devices that could run off of coin cell batteries for years, if possible.
Bluetooth Low Energy (also called Bluetooth LE, BLE or BTLE) is not compatible with Bluetooth Classic. A BLE and Classic device can’t communicate as they use different modulation schemes, different channels and bandwidth. But, devices that are Dual Mode contain both Bluetooth Low Energy and Bluetooth Classic which operate independent of each other.
You may have seen the Bluetooth Smart and Bluetooth Smart Ready monikers. These marketing slogans were used in the early days of Bluetooth LE to promote devices but because people used Bluetooth Low Energy and BLE to describe the technology, the Bluetooth SIG gave up and stopped promoting them.
It’s also interesting to note that the Bluetooth SIG discourages using BLE to describe Bluetooth Low Energy because BLE is trademarked by another entity, but in reality in everyday use everyone uses BLE. Bluetooth Smart devices referred to BLE only devices (so called Single Mode) while Bluetooth Smart Ready referred to Dual Mode devices that included classic. As you can tell, this marketing was more confusing than the original names.
BLE went through several evolutions itself, and the Bluetooth specification has gotten new features and fixes over the years that also updated the Bluetooth Classic, in particular the security aspects
- Bluetooth 4.0 – Introduced Bluetooth Low Energy (LE)
- Bluetooth 4.1 – Added features such as ability to operate as multiple roles, and LE Privacy v1.1
- Bluetooth 4.2 – Added Packet Length Extension (ability to send more data) as well as LE Secure Connections and Link Layer Privacy
Bluetooth LE Security
Bluetooth LE was designed to improve upon Bluetooth Classic in a few respects. One of these was privacy. In Bluetooth Classic, the MAC address representing the device was fixed and was transmitted publicly by the device. This meant that a user with a Bluetooth device could be tracked, something that is used in real life to track people in certain situations.
From a security perspective, Bluetooth 4.0 and 4.1 had a huge security flaw – the Secure Simple pairing (SSP) key exchange mechanism was weak and was broken. Bluetooth 4.2 fixed this and introduced LE Secure Connections which leverage Elliptic-Curve Diffie-Hellman (ECDH) to help exchange the encryption key. This update was also applied to Bluetooth Classic which used SSP.
One downside to the fact Bluetooth has evolved over time is that there are a lot of devices with known issues, some of which will never be patched or updated. This is especially true of Bluetooth Classic devices because firmware updates over the air are a capability rarely implemented in them. BLE has had much more support for this capability, but it depends primarily on the vendor. Backwards compatibility is a huge objective for the specification, which can sometimes result in weak to no security, especially when using older devices that don’t support the latest security features.
After Bluetooth 4.2, came several other updates to the specifications:
- Bluetooth 5 – Added LE 2Mbps PHY for higher throughput in BLE along with other fixes
- Bluetooth 5.1 – Added Angle of Arrival / Departure, HCI support for debug keys in LESC
- Bluetooth 5.2 – Added LE Audio using LE Isochronous Channels
- Bluetooth 5.3 – Added Host controller encryption key control enhancements, enhanced connection update and channel classification
- Bluetooth 5.4 – Added Periodic Advertising With Responses, Encrypted Advertising Data and LE GATT security levels characteristic
It’s important to note that, despite what some websites may show, the security in Bluetooth is complex and there are different capabilities in Bluetooth Classic compared to Bluetooth LE, although both in later specifications support secure pairing capabilities. Some articles seem to mix both, causing even more confusion. We’ll work to demystify this.
Bluetooth Classic BR/EDR Security
Bluetooth Classic security has been an evolving journey. Early versions of Bluetooth were and remain insecure, with attacks to various aspects of the protocol.
Differences between Classic and LE
Before we jump into the security aspect, a word about Bluetooth is warranted. Bluetooth classic is an ISM band protocol that uses the 2.4GHz band for communication, intended for relatively short range and low power communications. Bluetooth devices arrange themselves into a Bluetooth Network called a piconet. This network has one master – a device whose clock is used to synchronize all the devices in the network, and up to 7 slave devices.
Bluetooth Classic uses 1Mbps GFSK for communicating at the Basic Rate (BR), and can switch to other modulations in Enhanced Data Rate (EDR) of 2Mbps and 3Mbps. But when it first connects, a device will use BR to communicate.
Encryption Mechanism and Protocol
Bluetooth Classic uses as its base communication method the Link Manager Protocol (commonly referred to as LMP). This is a lower level protocol that is used over the air (and during testing, via cable) to setup the link and control for BR/EDR. It’s important to know that LMP is not encrypted or authenticated. It’s important to understand it because LMP messages are used to configure the security of the device.
The actual encryption in Bluetooth Classic depends on capabilities. Devices that support Secure Connections will use AES CCM algorithm as defined in IETF RFC 3610. If they don’t, the devices will encrypt using the Bluetooth proprietary E0 stream cipher which is based on the Massey-Rueppel stream cipher. E0 is problematic and there are many attacks against it in the literature going back almost 20 years. These attacks reduce the key space significantly, to where with some computation time it’s possible to brute force the key.
Now, let’s go over the Bluetooth communication process. Two Bluetooth devices that have never met want to connect. Because of this, they need to establish some security information which are keys used in encrypting the data. The creation of the keys and sharing them is called pairing (hence why they’re a shared key). But since the link isn’t secure, if they sent the keys to each other they can be easily sniffed by an attacker. So there needs to be a secure mechanism to share keys between two devices. This is the pairing process. In Bluetooth Classic, there are two pairing options:
Legacy Pairing – This is the old mechanism for pairing that has been broken and should be avoided. It uses the E21 or E22 algorithms based on SAFER+. In legacy pairing, the only source of entropy is the PIN which is usually 4 digits. This pin is oftentimes fixed in devices that have no keyboard/display. It’s therefore possible to run a search and brute force the key.
Secure Simple Pairing (SSP)– This is the updated mechanism that uses the well-known ECDH algorithm
So for any device, you definitively want Secure Simple Pairing to be used.
Now that the keys have been shared, we can use them to actually encrypt the connection. You may be wondering why we go through this process. Aside from the fact that public key cryptography allows two parties that have never met each other to exchange information securely, it’s common to use public key cryptography for sharing the key while using symmetric key cryptography for the actual encryption. This is done for efficiency and power consumption reasons. So once the keys are in place.
For legacy devices, the E0 encryption algorithm will be used, but for devices that support the Secure Connections feature (which should be all of them by now) the more secure AES-CCM algorithm will be used for encrypting the data.
Bluetooth Classic BR/EDR Security Modes
We will first cover the Bluetooth Classic security mode, referred to as BR/EDR Security modes which apply only to Bluetooth Classic. Bluetooth classic has two main groups of Security Modes, which are different ways the Bluetooth security supports (that each has certain level of security).
- Legacy Security Modes – These are modes that apply to a controller or host that doesn’t support Secure Simple Pairing (SSP)
- SSP Security Modes
Security mode 1 – Non Secure
In this mode, a Bluetooth device will never initiate any security procedure
Security Mode 2 – Service Level Security
In this mode it will not initiate any security procedure before an L2CAP_CONNECTION_REQ has been received or a channel establishment procedure has been initiated by itself.
Security Mode 3 – Link Level Security
In security Mode 3, a Bluetooth device will initiate security procedures before it sends the LMP_SETUP_COMPLETE message
All these modes should not be used as SSP should always be used.
Security Mode 4 – Service Level Security
For Security Mode 4, there are multiple levels used to enforce the security of the services provided by the device. These security settings are stored in a security database on the device
- Level 0
- No Authentication of remote device
- No Man in the Middle (MITM) protection
- No Encryption
- No user interaction
This mode is only used for certain services
- Level 1
- Authentication required when encryption is enabled
- MITM protection not necessary
- Encryption only required for non-SDP service
- Minimal user interaction
- Level 2
- Authentication required
- MITM protection necessary
- Encryption desired
- Level 3
- Authentication required
- MITM protection required
- Encryption required
- User interaction acceptable
- Level 4
- Authentication required
- MITM required
- Encryption required
- User Interaction acceptable
- Link Key is P-256 based SSP and Secure Authentication
- This level required Secure Connections on both ends
These modes and levels are meant to give the product designer the ability to tradeoff security and convenience. As the security level increases, the user interaction increases. Level 0 provides no security, while Level 4 is the most secure and requires the user to interact.
Bluetooth Association Models
These models determine how Secure Simple pairing associates and depend on the Input/Output (IO) of the devices. For example, a smartphone will have both a display or keyboard, while an implanted medical device will have neither.
- Numeric Comparison – a number is displayed on the two devices and the user confirms the number is identical
- Just Works – Used for devices with no Display or Keyboard
- Out of Band – Use a mechanism that is not based on Bluetooth to associate. For example, using NFC
- Passkey Entry – used in a scenario where there’s input capability but no display. The user enters the passkey into the device
The purpose of the Bluetooth association modes is to provide security against MITM attacks. With the Just Works
Bluetooth Low Energy Security
Bluetooth Low Energy came to be in 2010, when the Bluetooth SIG adopted the Bluetooth 4.0 specification. LE was adopted because Bluetooth Classic required too much power, took too long to connect, and was too expensive to implement. Classic is also very complex, with multiple layers dealing with the data.
Bluetooth Low Energy may share the same name as Classic, but it’s different in a lot of ways (while sharing others). It also uses GFSK but with a slightly different modulation and different bandwidth. The two are not compatible, so you can’t connect them. A few parameters of Bluetooth Low Energy are:
- 1Mbps GFSK Radio
- 40 Channels
- 1MHz Bandwidth
- Adaptive Frequency Hopping
Much like Bluetooth Classic, BLE also has a legacy and non-legacy pairing modes. In fact the legacy pairing protocol was so bad that the Bluetooth SIG released the Bluetooth Specification v4.2 with LE Secure Connections. Notice that while it says connections, LSC added a new pairing mechanism as well.
As opposed to Bluetooth Classic, BLE always uses AES-CCM for encrypting the data. There’s no E0 or other stream cipher. But, the Key exchange protocol during pairing was the vulnerability that forced a change. The original Key Exchange protocol is a custom protocol invented by the Bluetooth SIG and it was vulnerable. The Bluetooth SIG actually knew about the vulnerability and they wrote in the specification that the pairing method doesn’t provide protection against a passive eavesdropper.
The Legacy Pairing in Bluetooth LE was present in Bluetooth 4.0 and Bluetooth 4.1. Devices supporting those specifications are therefore vulnerable to Crackle attack.
Bluetooth Cross-transport Key Derivation CTKD
Many Bluetooth devices connect using both Bluetooth Classic or Bluetooth Low Energy. For example, audio devices to smartphones. Because both BLE and Classic use different pairing mechanisms, generating and using more than one key was not desirable, since it affects the user experience. Cross-transport Key Derivation is a mechanism created to solve this issue by which the key can be shared between the two transports. Only one transport needs to go through the pairing process. However, the BLUR attack discovered in 2020 found several security issues.
LE Privacy
We talked earlier about the fact that the Bluetooth MAC address for Bluetooth Classic is fixed and can’t be changed. One of the objectives of Bluetooth LE was to improve privacy and prevent tracking. To allow for privacy, the address of a BLE device can change periodically to avoid tracking a device by its address. This privacy feature is enabled in many devices such as iPhones (and other iOS devices).
If the MAC address is constantly changing, how can a device reconnect ? How can a headset know that the iPhone it’s connecting to is the same device? The key is that the MAC address is changing in a calculated way. The MAC address set based on a cryptographic key called the Identity Resolution Key (IRK) that allows a device to check whether the MAC address matches the device. This key is exchanged as part of the keys during pairing and bonding.
Bonding
We’ve talked quite about pairing and encryption, but there’s another important step when securing Bluetooth and that’s Bonding. Bonding is nothing more than creating a permanent bond between two devices by storing the keys that have been exchanged. These keys are stored in the system, ready to be used. For small devices, the keys are usually stored in Flash, and on computer systems the hard drive or other locations may be used depending on implementation.
One attack that can be employed is to extract the keys from Flash or other storage in order to decrypt communications. Some devices provide a secure location where keys can be placed to prevent this attack, but most devices don’t have this protection. Leveraging flash security that prevents reading back firmware from a device can be helpful in protecting the keys, although this can and has been attacked.
Recommendations for building secure Bluetooth Products
Whether you’re building a Bluetooth Classic, BLE or Dual Mode product, there’s a set of recommendations that you should follow:
- Use Bluetooth Devices and stacks with the latest version of the Bluetooth Specification – this will ensure you’re avoiding many of the issues of earlier specifications. The Bluetooth SIG forces this by withdrawing and deprecating older specifications. You can no longer certify a v4.1 or earlier device. Currently the latest specification available is v5.4
- Review the Bluetooth SIG errata and security notices – these can alert you to potential issues or things you should address in your design
- Enforce the highest level of security mode and level possible – every device is different and has different I/O capabilities, but you should work to secure the product as much as possible. Leverage displays and keyboards as possible to protect against MITM attacks as much as possible
- Plan on upgrading your device’s firmware and the Bluetooth Stack as well. Patching for vulnerabilities is a way of life for systems, and it helps keep your products as secure as possible
Security is not absolute. It is always a tradeoff between security, convenience, user experience and implementation. It’s up to every product designer to find the right balance. The good news are that Bluetooth makes it easier than ever to leverage security while minimizing the impact.