Bluetooth Low Energy (BLE) (commonly referred to as Bluetooth LE) is a wireless technology designed for energy-efficient data exchange between devices. A major advantage of BLE over Bluetooth Classic is its optimization for battery-powered applications. The evolution of BLE security features is defined in the Bluetooth specification, which continues to address new threats and improve privacy and authentication standards.
BLE is widely used everywhere in devices such as smartwatches, fitness trackers, home automation systems, and medical devices. Its energy efficiency and ease of use make it a preferred choice in both consumer technology and critical healthcare applications. Great connectivity comes with great responsibility, especially when it comes to security. Since BLE is deeply integrated into our daily lives, understanding its vulnerabilities is key to protecting both data and privacy.
What is the Need for a Secure BLE Connection?
- Secure BLE connections are required to protect confidential data exchanged between devices and restrict unauthorized access. With its widespread use in healthcare devices, smart home systems, and IoT gadgets, BLE poses significant risks if compromised, including data breaches, device manipulation, and privacy violations. User data is protected in BLE using strong security features. These protections rely on key features and security capabilities such as LE Secure Connections, encryption, authentication, privacy features, and industry-standard cryptology, which must be properly supported, configured, and tested.
- Understanding these risks and threats requires some prior knowledge of BLE security concepts and the varying levels of protection available within BLE security modes. Some security issues associated with BLE include:
- Passive eavesdropping: A process where an unauthorized device listens to the data exchanged between two paired devices.
- Device Spoofing: Device impersonating as another trusted device to gain privileges.
- Man-in-the-Middle Attacks (MITM): An unauthorized third party intercepts and manipulates data exchanged between two connected BLE devices.
- Replay Attacks: An attacker records network traffic and later re-submits the captured packets to gain unauthorized access.
Common Vulnerabilities in BLE Systems
Bluetooth Low Energy (BLE) systems, while offering efficient and flexible wireless connectivity, are exposed to a range of vulnerabilities that can threaten the security and privacy of both devices and users. Recognizing these risks is crucial for developers aiming to implement robust security features and for users who rely on BLE devices to protect their sensitive data.
- Man-in-the-Middle (MITM) Attacks: A classic threat in wireless communication, MITM attacks occur when an attacker secretly intercepts and possibly alters the data exchanged between two devices. BLE is particularly vulnerable during the pairing process, especially if insecure pairing methods like “Just Works” are used. To counteract this, modern BLE security leverages LE Secure Connections pairing, which uses Elliptic Curve Diffie-Hellman (ECDH) for key exchange, making it significantly harder for attackers to compromise the connection.
- Weak Authentication Mechanisms: Some BLE devices, especially those with limited input/output capabilities, may default to less secure pairing methods. For example, the “Just Works” association model does not require user verification, leaving devices open to unauthorized access. In contrast, authenticated pairing methods such as Passkey Entry and Numeric Comparison require user interaction, providing a higher level of security and protection against MITM attacks.
- Insufficient Encryption: Not all BLE devices implement encryption with the same rigor. Devices that use weak keys or fail to properly establish a secure connection are susceptible to passive eavesdropping and data interception. LE Secure Connections ensure that encryption keys are exchanged securely, maintaining data integrity and confidentiality throughout the connection.
- Privacy Concerns and Device Tracking: BLE devices can be tracked using their static MAC addresses, posing a risk to user privacy. To address this, modern BLE devices support MAC address randomization, periodically changing their address to prevent long-term tracking and unauthorized device identification.
- Replay Attacks: In a replay attack, an adversary captures valid data transmissions and replays them to trick the receiving device. BLE combats this by incorporating counters or timestamps into encrypted messages, and by using data signing—a key feature of LE Secure Connections—to verify the authenticity and integrity of exchanged data.
- BlueBorne and Other Exploits: Vulnerabilities like BlueBorne have demonstrated that attackers can exploit weaknesses in the Bluetooth stack to gain control over devices without user interaction. Keeping BLE devices updated with the latest security patches and firmware is critical to closing these security gaps.
- Limited I/O Capabilities: Devices such as fitness trackers or medical devices often lack displays or input methods, restricting them to less secure pairing methods. This limitation can make it challenging to implement strong authentication mechanisms, so developers must carefully consider the security mode and capabilities of each device.
- Out-of-Band (OOB) Data Leakage: When pairing is performed using out-of-band channels, such as NFC or QR codes, improper handling of OOB data can lead to unauthorized access. Ensuring secure storage and transmission of OOB data is essential to prevent leaks and maintain a secure connection.
Mitigation Strategies: To effectively protect BLE devices and the sensitive information they handle, developers should:
- Implement LE Secure Connections pairing and authenticated pairing methods wherever possible.
- Use strong encryption and data signing to ensure data integrity and confidentiality.
- Enable MAC address randomization to enhance privacy.
- Regularly update device firmware to address newly discovered vulnerabilities.
- Choose pairing methods that match the device’s I/O capabilities while maximizing security.
By understanding these common vulnerabilities and applying robust security concepts, developers and users can ensure that their BLE devices maintain secure connections, protect sensitive data, and resist evolving threats in the wireless landscape.
What are the Options to Overcome BLE Security Issues?
Prevent Device Tracking
Device tracking related issues can be addressed by MAC (Media Access Control) address randomization and selective advertising.
MAC Address Randomization
To prevent long-term tracking, this method utilizes rotating BLE MAC address that changes either at regular intervals or with each new connection. There are two modes as below:
Resolvable Private addresses (RPAs): These are periodically changing addresses generated using an Identity Resolving Key (IRK), enabling only trusted devices to verify the device’s identity. Non-resolvable private addresses: The primary use of these addresses is in broadcast-only scenarios or with devices intended for one-time use.
Selective Advertisement
In this mechanism, device advertising is resumed solely in response to user interaction. The developer can restart advertisement only on a button-press event, rather than automatically after a disconnection. This approach helps restrict the visibility of advertising data to potential attackers. Authentication and data encryption
Pairing
Pairing secures connection by encrypting the data. Pairing and bonding can be used for encrypted data exchange.
BLE pairing methods are differentiated depending on the device’s I/O capabilities. Different association models are used in BLE pairing, such as Just Works, Passkey Entry, Numeric Comparison, and Out of Band (OOB), depending on the I/O capabilities and security requirements of the devices.
Authenticated pairing methods play a crucial role in protecting against passive eavesdropping and man-in-the-middle (MITM) attacks by ensuring secure authentication before communication.
During pairing, authentication data is exchanged between devices, which is essential for establishing a secure connection and preventing unauthorized access.
In OOB pairing, a separate band channel, such as NFC, is used to securely exchange authentication data outside the main Bluetooth radio channel, enhancing protection against interception.
Pairing scenarios may involve cases where only one device has limited I/O capabilities, which affects the choice of association model and pairing method.
What are the Different BLE Pairing Methods?
- Just Works: This is the least secure pairing method and allows pairing without authentication. It is used when a device does not have any I/O capabilities like keyboard or display. This is not protected against MITM.
- Passkey Entry: In this method, the user must enter a six-digit passkey on the device, which is displayed on another device. This method is MITM protected, so the attacker cannot generate this number.
- Numeric Comparison: In this method, numbers are displayed on both devices that are intended to connect. If numbers are identical, the user can accept pairing on the device. In case of different numbers, the user should reject connection. This method is MITM protected.
Earlier Bluetooth Low Energy pairing methods, such as le legacy and legacy pairing (introduced in Bluetooth 4.0 and 4.1), use less advanced security features and rely on the short term key (STK) for initial encryption. These are being replaced by more secure options like LE Secure Connections.
Encryption
Long term key (LTK) is used to encrypt a BLE connection that is exchanged during the pairing process. In LE Legacy Pairing, a short term key (STK) is generated during the initial pairing phase to provide encryption before the LTK is established and bonded for future use. Encryption provides MITM protection during data transfer between devices.
Below is the BLE sniffer screenshot to showcase encrypted connection. LTK is required to decrypt packets.
Bonding
It is the process of storing pairing information. For bonded devices, the pairing process does not need to be repeated on every reconnection. Long-term keys (LTKs) stored during bonding enable secure future connections without repeating the pairing process.
There are several options to store device bonding information. Bluetooth security can be enabled without bonding.
Application-level security
This is an optional security that a developer can add at the application layer. The developer can use ECDH (Elliptic Curve Diffie-Hellman), RSA (Rivest-Shamir-Adleman), or another digital signature algorithm to achieve this.
We have demonstrated the ECDH key exchange mechanism below:
The Steps Used Are:
- Key Pair Generation: Both devices generate public and private keys.
- Key Exchange: Devices exchange their public keys over the air.
- Shared Secret Calculation: The shared secret is calculated using the device’s own private key and the public key of the other device. To ensure security, the shared secret is never sent wirelessly between the devices. It serves as the foundation for encryption and authentication process in BLE communication.
- Validation and Connection Establishment: To establish a secure connection between the two devices, the shared secrets generated by these devices must match. If both the shared secrets do not match, it indicates potential security issues like unauthorized devices attempting to connect. In such cases, the developer can drop the BLE connection.
BLE Security Controls in Zephyr RTOS
In this section, we have explained how to configure BLE security by taking Zephyr RTOS as an example.
BLE Security Levels
Different BLE Security levels can be configured based on the encryption and authentication requirements.
- Level 1: No encryption and no authentication (Just Works)
- Level 2: Encryption and no authentication (No MITM)
- Level 3: Encryption and authentication (MITM)
- Level 4: Authenticated secure connections and 128-bit key
To configure a security level, bt_conn_set_security() API needs to be called in the connected callback of the application as shown below:
{
char addr[BT_ADDR_LE_STR_LEN] = {0};
bt_addr_le_to_str(bt_conn_get_dst(conn), addr, sizeof(addr));
if (conn_err) {
printk(“Failed to connect to %s (err %u)\n”, addr, conn_err);
return;
}
printk(“Connection from %s\n”, addr);
(void)mtu_exchange(conn);
err = bt_conn_set_security(conn, BT_SECURITY_L2);
if (err) {
printk(“Failed to set security (err %d)\n”, err);
}
}
A callback function must be defined to notify when the security level changes, as illustrated below:
{
char addr[BT_ADDR_LE_STR_LEN];
bt_addr_le_to_str(bt_conn_get_dst(conn), addr, sizeof(addr));
if (!err) {
printk(“Security level changed %s %u\n”, addr, level);
} else {
printk(“Failed to set security level %s %u (err %d)\n”, addr, level, err);
}
Callbacks need to be defined using bt_conn_cb struct and registered using bt_conn_cb_register() API or BT_CONN_CB_DEFINE as shown below:
.connected = connected,
.disconnected = disconnected,
.security_changed = security_changed,
.le_param_req = le_param_req,
.le_param_updated = le_param_updated,
};
Next, we will have to add a few callbacks for authenticated pairing as shown below:
static void auth_cancel(struct bt_conn *conn)
{
char addr[BT_ADDR_LE_STR_LEN];
bt_addr_le_to_str(bt_conn_get_dst(conn), addr, sizeof(addr));
printk(“Pairing cancelled\n”);
}
static void pairing_complete(struct bt_conn *conn, bool bonded)
{
char addr[BT_ADDR_LE_STR_LEN];
bt_addr_le_to_str(bt_conn_get_dst(conn), addr, sizeof(addr));
printk(“Pairing completed\n”);
}
static void pairing_failed(struct bt_conn *conn, enum bt_security_err reason)
{
char addr[BT_ADDR_LE_STR_LEN];
bt_addr_le_to_str(bt_conn_get_dst(conn), addr, sizeof(addr));
printk(“Pairing failed, reason %d\n”, reason);
}
static struct bt_conn_auth_cb conn_auth_callbacks = {
.passkey_display = NULL,
.passkey_confirm = NULL,
.cancel = auth_cancel,
.pairing_confirm = NULL,
.pairing_complete = pairing_complete,
.pairing_failed = pairing_failed
};
The callback added needs to be registered using bt_conn_auth_cb_register() API as illustrated in the process below.
If bonding is enabled, the settings are loaded using this call:
Include the settings file from which the above call is made.
BT_GATT_CHARACTERISTIC(&auth_uuid.uuid, BT_GATT_CHRC_WRITE | BT_GATT_CHRC_NOTIFY, BT_GATT_PERM_WRITE_ENCRYPT, NULL, auth_cb, NULL),
BT_GATT_CCC(auth_cfg_changed, BT_GATT_PERM_READ_ENCRYPT | BT_GATT_PERM_WRITE_ENCRYPT));
To prompt the mobile application to initiate system pairing when trying to write on a characteristic, BT_GATT_PERM_WRITE_ENCRYPT flag should be set. You can refer the example below:
Bonding
To enable Bluetooth security without bonding, the following configurations must be configured in the prj.conf file:
CONFIG_BT=y
CONFIG_BT_SMP=y
# Required to disable bonding
CONFIG_BT_BONDABLE=n
Methods to Store Bonding Information
If bonding has to be enabled, there are multiple ways to store bonding information. You can store the bonding information in Zephyr as follows:
1. Using Non-Volatile Storage (NVS)
Add the following configurations to prj.conf to store the bonding information in NVS:
CONFIG_BT_SETTINGS=y
CONFIG_SETTINGS=y
CONFIG_NVS=y# Flash Configurations
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
2. Using Little File System (LFS)
Add the following configurations to prj.conf to store the settings file in LFS:
CONFIG_BT_SETTINGS=y
CONFIG_SETTINGS=y
CONFIG_SETTINGS_FILE=y
CONFIG_SETTINGS_FILE_PATH=”/lfs1/settings.txt”
# File system configurations CONFIG_FILE_SYSTEM=y
CONFIG_FILE_SYSTEM_LITTLEFS=y
- To add entry into a circular buffer
Call fcb_append() to get the location where data can be written. If this fails, then call fcb_rotate() that deletes the oldest sector and then call fcb_append() again.
fcb_area_write() is used to write the entry content.
fcb_append_finish() is used to complete writing. - To read contents of a circular buffer
fcb_area_read can be used to read the entry content.
4. Using Zephyr Memory Storage (ZMS)
Zephyr Memory Storage (ZMS) is a recently introduced storage system that operates on a key-value model. The ZMS system organizes memory into sectors, with each sector sequentially filled with key-value data until its capacity is reached.Selective advertisement
The user can enable selective advertising in Zephyr as shown below. Here, the GPIO (General Purpose Input/Output) callback is demonstrated where the BLE advertisement restarts after disconnection.
{
ARG_UNUSED(dev);
ARG_UNUSED(cb);
ARG_UNUSED(pins);
uint8_t model_number[MODEL_NUMBER_LENGTH + 1] = {0};
get_model_number(model_number);
const struct bt_data scan_data[] = {
BT_DATA(BT_DATA_NAME_COMPLETE, model_number, MODEL_NUMBER_LENGTH),
};int err = bt_le_adv_start(BT_LE_ADV_CONN_FAST_1, advertisement_data, ARRAY_SIZE(advertisement_data), scan_data, ARRAY_SIZE(scan_data));
if (err) {
printk(“BT Failed to start advertisement (err %d)\n”, err);
return;
}
}
Comparative Analysis of Android and iOS Behavior for Different BLE Security Levels
Android and iOS have different behaviors with respect to security levels. We have listed some observations with respect to the Zephyr RTOS below.
| Test case | Device and security level | Observation |
| 1. Fresh connection 2. Disconnect from phone 3. Forget device 4. Reconnect | iPhone device, BLE security L2 | No pairing popups. FW fails to set security with (err 4) but the device connects successfully. Data is not encrypted. |
| Android device, BLE security L2 | Pairing popups appear. FW fails to set security with (err 4) and the device cannot connect. | |
| 1. Fresh connection 2. Disconnect from phone 3. Forget device 4. Reboot device 5. Reconnect | iPhone device, BLE security L2 | No pairing popups. FW fails to set security with (err 4) but the device connects successfully. Data is not encrypted. |
| 1. Fresh connection 2. Disconnect from phone 3. Remove settings file from lfs (like factory reset) 4. Reboot device 5. Reconnect | iPhone device, BLE security L2 | Connects successfully by pairing popups but pairing fails. It means data is not encrypted. |
Conclusion:
Securing BLE connections is required to protect sensitive data and ensure reliable communication in embedded systems. Techniques like MAC address randomization, selective advertising, secure pairing methods, and application-layer encryption provide defense against common threats such as device tracking, MITM attacks, and passive eavesdropping. By using these strategies and integrating security features, developers can make secure, efficient, and trustworthy BLE-enabled devices.
