Bluetooth Low Energy (BLE) has become the wireless protocol of choice for everything from wearables to medical devices and asset trackers. But as its reach expands into more sensitive and personal applications, the security and privacy of BLE communications are no longer optional—they’re essential.
In this article, we dive into key aspects of BLE security and privacy, including pairing methods, LE Secure Connections, MAC address randomization, and how BLE defends against tracking.
Modern BLE security is centered around LE Secure Connections, introduced in Bluetooth 4.2, which uses Elliptic Curve Diffie-Hellman (ECDH) to provide encryption and protection against man-in-the-middle (MITM) attacks.
BLE supports different pairing methods based on device capabilities—ranging from Just Works (least secure) to Passkey Entry and Numeric Comparison (both MITM-resistant). Developers should choose methods offering higher authentication when possible.
On the privacy side, BLE has evolved to address concerns around device tracking. Features like MAC address randomization (resolvable and non-resolvable) and advertising data minimization help prevent persistent tracking of users.
To build secure BLE devices, developers should:
- Use LE Secure Connections by default.
- Avoid Just Works unless absolutely necessary.
- Encrypt GATT data after bonding.
- Implement MAC randomization to resist tracking.
Together, these practices help protect both the data integrity and user anonymity in BLE-enabled products.
🔑 LE Secure Connections (Introduced in Bluetooth 4.2)
One of the most important upgrades to BLE security came with LE Secure Connections, a feature that replaced legacy pairing with a more robust key exchange mechanism. LE Secure Connections uses Elliptic Curve Diffie-Hellman (ECDH) to establish shared secrets, which dramatically reduces the risk of man-in-the-middle (MITM) attacks.
Key benefits:
- Stronger encryption (128-bit AES-CCM)
- Eavesdropping protection via ECDH key agreement
- MITM protection (when combined with an authenticated pairing method)
This feature is mandatory for Bluetooth 5+ certified devices and is the default for Android and iOS platforms as of 2024.
How ECDH Works
ECDH follows a few simple steps. ECDH using asymmetric cryptography, which means that instead of the same key being used for decryption and encryption, there are two keys, a private and public key. These are the main steps of ECDH in BLE
- Key Pair Generation:
- Each BLE device generates a private key and a public key using an elliptic curve (typically P-256).
- Key Exchange:
- Devices exchange their public keys over the air.
- Shared Secret Calculation:
- Each device uses its private key and the other device’s public key to compute the same shared secret.
- This is possible due to the mathematical properties of elliptic curves.
Importantly, even if someone is eavesdropping on the public key exchange, they cannot compute the shared secret without access to either private key.
Key Pair Generation
Each device (say, A and B) generates:
- A private key (kept secret)
- A corresponding public key using the elliptic curve equation (usually the P-256 curve). known base point on the curve.
Public Key Exchange
- Devices exchange public keys over the BLE link.
- This happens during the pairing feature exchange phase.
Shared Secret Calculation
- Each device uses its own private key and the other device’s public key to compute the shared secret:
- Thanks to properties of elliptic curves, both devices compute the same 256-bit shared secret—without sending it over the air.
🔒 What It Secures
- The Long Term Key (LTK) derived from the shared secret is used to encrypt future communications.
- When paired with authenticated pairing methods (e.g., Passkey or Numeric Comparison), ECDH also protects against MITM attacks.
Once the shared secret is established, we Derive the Session Keys. To do so, the shared secret is passed through a key derivation function (KDF) to produce:
- Long Term Key (LTK) – 128-bit symmetric key used for encrypting future BLE connections every time through
- CSRK (Connection Signature Resolving Key) – optional, for data signing
The LTK is the most important key in BLE. If an LTK is leaked, both past and future connections can be decrypted.
Understanding BLE Security in Pairing and Reconnection
The initial pairing between the devices, if the devices bond, the LTK is stored after the exchange.
What happens when you try to reconnect to a BLE device? After all, you don’t expect you will need to re-pair every time? Instead, when two devices connect, they know that the’yve been connected before. They check the device’s MAC address against the bonding list and realize they already have keys associated with that device.
In this case we begin the Reconnection procedure:
The Initiating device sends a Start Encryption Request.
This includes:
- The Encrypted Diversifier (EDIV)
- A Random number (Rand)
These values identify which LTK to use (if multiple keys are stored). The receiving device looks up the matching LTK using the received EDIV and Rand.
✅ Summary Benefits in BLE
- Stronger encryption than legacy pairing
- No transmission of keys over the air
- Foundation of LE Secure Connections
- Default on most BLE 5+ platforms (Android, iOS)
🤝 Just Works vs Passkey vs Numeric Comparison
Now, it’s important to realize that you need to make sure that the public key you receive actually comes from the device you’re trying to connect to. An attacker sitting in the middle performing a Man-In-The-Middle Attack will try to send their information, making your device thing you’re connected to the other device when in fact you’re connected to the attacker.
To prevent this vulnerability and make sure you can guarantee you’re connected to the right device, the Bluetooth Specification adds association models.
BLE devices can use different association models during pairing depending on their I/O capabilities and the level of security required. The association model you use determines whether you are protected against MITM or not.
| Method | MITM Protection | User Input Required | Typical Use Case |
|---|---|---|---|
| Just Works | ❌ No | None | Smart bulbs, basic sensors |
| Passkey Entry | ✅ Yes | Yes (6-digit input) | Keyboards, secure wearables |
| Numeric Comparison | ✅ Yes | Yes (confirm match) | Phones, tablets, apps with screens |
Just Works is the least secure mechanism, as it allows pairing without authentication, making it vulnerable to MITM attacks. It’s basically what you use when you don’t have any Input/Output capabilities in the devices. For example, you wouldn’t have a display or keyboard in a lightbulb.
Passkey Entry allows a user to enter a 6-digit passkey to a device that they see on another device. This passkey is generated using the secrets each device has, meaning that an attacker will not have the same number and can’t generate them (without breaking the cryptography which is a significant challenge).
Numeric Comparison is similar. In numeric comparison, numbers are shown on each device looking to pair. If the user sees identical numbers, they can accept the pairing on each device. Like in Passkey Entry, an attacker can’t see the numbers and a user that sees different numbers should reject the pairing.
Developers in general should avoid using Just Works wherever practical and use Numeric Comparison or Passkey Entry for higher trust applications. Realistically, the ability to defend against MITM attacks
🕵️♂️ Privacy Concerns in BLE
The original Bluetooth specification (now referred to as Bluetooth Classic) used a fixed MAC address, which meant you could be tracked. BLE was designed with Privacy in mind while still targeting low-power efficiency and ease of connectivity. its original specification posed a number of privacy challenges:
- Devices broadcast public MAC addresses, allowing tracking by passive observers.
- Advertising packets could include device names or IDs that remain static.
- Connection events and GATT operations are easily sniffable without encryption.
These issues opened the door for widespread passive tracking and profiling, especially in public spaces.
🔄 MAC Address Randomization
To combat tracking, Bluetooth devices now support MAC address randomization, mandated in many privacy-conscious platforms (e.g., Android, iOS). This technique involves rotating the BLE MAC address over time or per session, preventing long-term association of a device to a person.
There are two key modes:
- Resolvable Private Addresses (RPAs): Generated using the Identity Resolving Key (IRK), which allows trusted devices to recognize one another while remaining opaque to outsiders.
- Non-Resolvable Private Addresses: Used for maximum anonymity, ideal for broadcast-only or one-time-use devices.
MAC randomization is now default behavior on smartphones and modern BLE stacks and should be implemented in all new BLE devices that advertise publicly.
You can read more about BLE MAC addresses in our Guide on BLE MAC Addresses.
🧭 Tracking Resistance in Modern BLE Devices
Modern BLE security is designed to make tracking difficult, expensive, or impractical, though it’s important to understand that it’s not technically impossible. For example, it’s possible to fingerprint devices which makes them almost impossible to spoof. Strategies to make tracking more difficult include:
- Frequent MAC rotation (sometimes every few minutes)
- Scrambling advertising payloads
- Encrypting GATT characteristics after bonding
- Selective advertising: Only advertising when necessary or when user interaction occurs
Bluetooth 5.2 and later also introduced advertising sets and periodic advertising with sync info, allowing more flexible, privacy-aware communication schedules.
📋 Whitelisting
While BLE supports features like encryption and authentication, another layer of security and control comes from whitelisting—a simple yet powerful mechanism to restrict which devices can establish connections.
What Is Whitelisting in BLE?
Whitelisting is a security and filtering mechanism that allows a BLE device to ignore advertising or connection requests from unknown or unauthorized devices. In essence, it’s a list of trusted device addresses (usually Bluetooth Device Addresses, BD_ADDRs) that the BLE controller uses to decide whether to accept or ignore incoming packets.
It applies to:
- Advertisers (peripherals) filtering scan or connection requests
- Scanners (centrals) filtering received advertising packets
Only devices in the whitelist are allowed to interact.
How BLE Whitelisting Works
Whitelisting is implemented at the controller level in the Bluetooth stack. This means that decisions to accept or reject packets are handled efficiently in hardware or low-level firmware, which is ideal for resource-constrained embedded devices.
Here’s how it typically works:
- A central or peripheral creates a whitelist using the HCI (Host Controller Interface) commands.
- The whitelist can contain entries for:
- Public device addresses
- Random static or private resolvable addresses
- Once enabled, the BLE controller uses this list to filter connection or scan responses.
Why Use the BLE Whitelist
Without a whitelist, any BLE device can connect to your product. Although you can implement authentication after connection, this isn’t necessarily the best idea:
- Allowing a connection with an unknown device opens the attack surface further for that device to send packets that could exploit the product and bypass
- A connection consumes more power. the whitelist happens at the lowest level, where the Controller ignores the CONN_IND packet
Let’s give a real-life example. You’re developing a Medical Device using BLE that has to be secured. It’s an implantable device, so the battery is small. The User connects with a mobile phone, but you only want the user or a clinician to connect to it.
So you implement the whitelist in the product. By using the whitelist , you prevent other devices from connecting, which protects the device from unwanted connections.
Now, you may be asking, how do you allow the legitimate connections to be established? When no devices have been connected, the whitelist starts out disabled. Once the first device connects successfully, it is added to the whitelist and the whitelist is enabled. From that moment on, no other device can connect.
There are moments where we want to add other devices. Here you will need to disable the whitelist temporarily so a legitimate device can connect. How exactly this is done depends on the product. For example, many medical devices use magnets or buttons to make a user do this. While this opens a device up, it’s for a limited time and typically protected by further authentication mechanisms.
Benefits of Whitelisting
- Security: Reduces the surface area for unauthorized access or tracking and prevents connections unwanted connections
- Power Efficiency: Saves energy by reducing unnecessary scan/advertising processing and connections
- Performance: Reduces clutter in busy environments by ignoring irrelevant devices.
BLE Whitelisting Limitations
Adding BLE Whitelisting in practice can be quite an effort because using it requires a complete system approach or else it won’t work. While it provides some benefits, Whitelisting isn’t perfect and in practice has some limitations:
- Static Nature: Basic whitelisting doesn’t adapt dynamically—you must update the list manually when a new device is authorized.
- Privacy Complexity: When devices change addresses frequently (using RPAs), extra logic is required to resolve identities correctly. Usually this is handled by modern devices, but that isn’t always the case
- Not Encryption: Whitelisting is a gatekeeper but doesn’t replace pairing, authentication, or encryption.
🛡️ Takeaways for Developers
- Use LE Secure Connections by default—avoid legacy pairing.
- Choose Passkey Entry or Numeric Comparison wherever user interaction is possible. This starts from product design.
- Randomize MAC addresses in advertising and connection initiation.
- Always encrypt GATT characteristics that deal with sensitive information.
- Avoid broadcasting personal or device-identifying information in cleartext.
As BLE becomes a ubiquitous part of the modern device ecosystem, robust security and privacy controls are no longer optional—they’re expected. Whether you’re building a smart lock, fitness tracker, or medical sensor, implementing proper BLE security is critical to ensuring trust, regulatory compliance, and user confidence.
By understanding and applying the key techniques outlined above, you can design BLE-enabled products that are both connected and protected.
