BLE Security

What is BLE security?

BLE security is the collection of mechanisms in Bluetooth Low Energy that protect a connection between two devices and the data exposed over it. The relevant pieces are pairing (how two devices agree on keys), bonding (storing those keys for later connections), link encryption, authentication of the peer, authorisation of access to individual GATT characteristics, and privacy through resolvable private addresses that stop a device from being tracked by its Bluetooth address.

Pairing comes in two generations. LE Legacy Pairing (Bluetooth 4.0 and 4.1) derives keys from a temporary key that is zero for Just Works and a six-digit number for Passkey Entry; an attacker who captures the pairing can recover it by brute force in seconds. LE Secure Connections (Bluetooth 4.2 and later) uses an elliptic-curve Diffie-Hellman exchange on P-256, so a passive sniffer learns nothing. The pairing method then decides whether the peer is authenticated: Numeric Comparison and Passkey Entry protect against an active attacker in the middle, Just Works does not, and Out of Band depends on the second channel, for example NFC.

Where is it defined?

The Bluetooth Core Specification, published by the Bluetooth SIG, defines pairing, the Security Manager protocol, encryption and the LE security modes and levels. Security Mode 1 Level 4 is the strongest for a data connection: authenticated LE Secure Connections pairing with 128-bit encryption. NIST SP 800-121 Rev. 2 explains the mechanisms and gives configuration recommendations; its tables of threats and countermeasures are a good checklist for a device requirement specification. For consumer IoT, ETSI EN 303 645 sets baseline requirements such as no universal default passwords and secure communication, and in the EU the Radio Equipment Directive with the harmonised EN 18031 series makes cybersecurity of the radio interface a condition for the CE marking.

What it means in practice

In our IoT penetration tests of BLE products, from ESP32-based communication modules to household and medical appliances, the specification is rarely the problem. The implementation is. What we typically find:

• No security on characteristics. Writes that control the device, from unlocking to changing settings, are accepted by any central that connects, without pairing. The pairing dialogue exists only in the app, not in the firmware.
• Legacy pairing still enabled. The chip supports LE Secure Connections, but the firmware accepts a legacy pairing request, so an attacker simply asks for the weaker one.
• Application-layer authentication that is a constant. The app sends a fixed token after connecting. Sniff it once, replay it forever. Challenge-response tied to the bond would cost a few lines of code.
• Firmware updates over BLE without signature checks, which turns a sniffable protocol into a code execution path.
• Static addresses that let a device, and its owner, be tracked across locations.

The fix is usually architectural: require LE Secure Connections, reject legacy pairing, bind authorisation to the bond, set per-characteristic permissions in the attribute table, sign updates, and use resolvable private addresses. Analysing all of this needs a sniffer, a controllable central and the firmware, which is why BLE tests work best as grey box with hardware samples.

Common misunderstandings

“BLE has a range of ten metres, so attacks need to be close” ignores directional antennas and the phone in the attacker’s pocket in the same room. “The app requires a login” means nothing if the device does not check who connects. And encryption in the link layer does not authorise anything: a device can be fully encrypted and still let any paired phone open the lock.