Bluetooth Low Energy: when legacy pairing and chatty characteristics betray your devices

Two new DVID trainings to explore the blind spots of Bluetooth Low Energy security

Bluetooth Low Energy is everywhere. Fitness trackers, medical sensors, smart locks, portable industrial equipment, connected toys. Its ease of implementation and low power consumption make it a reference protocol for IoT devices. But this same simplicity has a downside: BLE security depends almost entirely on the choices made by the developer, and those choices are rarely the right ones.

Two new DVID trainings explore these blind spots through concrete scenarios. The first tackles BLE legacy pairing, inherited from Bluetooth 4.0 and still used on products sold today. The second addresses a more discreet but formidable flaw: sensitive information leaking through a poorly designed GATT characteristic.

BLE legacy pairing / Bluetooth 4: a broken mechanism we keep using

Bluetooth 4.0 introduced BLE in 2010, with a pairing model now considered cryptographically weak. Version 4.2 brought LE Secure Connections based on ECDH, which solves most of the problems. More than fifteen years later, many deployed devices — including in medical and industrial environments — still use legacy pairing.

This training's scenario puts the participant in the role of an attacker within radio range of the device. The goal: capture the pairing, derive the session keys from it, and decrypt all the BLE traffic that follows. Participants learn how to:

• sniff BLE traffic with a suitable probe and identify pairing packets;
• recognize the pairing modes in use (Just Works, Passkey Entry, Out of Band);
• exploit the cryptographic weaknesses of legacy pairing to rebuild the TK and then the STK;
• decrypt the following exchanges and rebuild the application content (sensor data, commands, credentials);
• tell apart what can be exploited passively (listening only) from what requires an active attack (MitM).

What makes this module particularly instructive is that it highlights an industrial reality: the Bluetooth version advertised on the product sheet says nothing about the pairing modes actually supported. A device can display "Bluetooth 5.2" and still accept legacy connections for backward compatibility. The training teaches how to detect these configurations in practice.

This issue falls under Annex I of the Cyber Resilience Act — requirements 2c (integrity), 2g (protection against unauthorized communications) and 2h (data confidentiality). It is also at the heart of the ETSI EN 303 645 recommendations on consumer IoT security.

Information leak on a BLE characteristic: the overly chatty GATT

The second training changes scale. No need to break any cryptography: here, sensitive information is accessible because the device deliberately exposes it, in a GATT characteristic readable without authentication.

GATT (Generic Attribute Profile) is the logical layer that structures the services and characteristics of a BLE device. Each characteristic has read, write and notification permissions. And these permissions are precisely where design mistakes concentrate. Participants explore:

• how to enumerate all services and characteristics of a BLE device from a smartphone or a PC;
• how to identify characteristics that expose more than they should — serial numbers, user identifiers, internal configuration, historical sensor data;
• how to link these leaks to exploitable information: indirect geolocation, user profiling, identifiers enabling targeted attacks;
• how to audit a BLE firmware to spot these misclassified characteristics before going to market;
• how to apply the least privilege principle to a GATT (encryption required, authentication, per-characteristic authorization).

This module highlights an often underestimated mechanism: BLE developers think in terms of exposed features, not in terms of information surface. A characteristic that returns an internal identifier "for debugging" becomes, once in production, an exfiltration channel available to anyone within a few meters.

This flaw covers requirements 2h (confidentiality), 2k (attack surface minimization) and 2d (access control) of CRA Annex I.

A 100% hands-on approach, true to DVID's DNA

These two trainings extend our teaching method: real hardware, a real protocol, and scenarios reproducible in a professional environment. Learn by doing, not by theorizing — this is especially true for BLE, where the official documentation is dense and the tools are many.

Participants work with:

• a target device based on ESP32 or nRF52, running an intentionally vulnerable BLE firmware;
• a BLE capture probe (dedicated sniffer such as an nRF52840 dongle);
• standard tools of the BLE ecosystem;
• Wireshark.

Each scenario is progressive. The legacy pairing module introduces the necessary cryptographic concepts step by step. The GATT module helps build an audit checklist that can be applied right away.

Key takeaways for participants

Beyond each scenario, these two modules build the essential reflexes for any team developing or auditing BLE:

• enforce LE Secure Connections (Bluetooth 4.2+) and explicitly disable legacy pairing;
• choose a pairing mode suited to the device's interface — avoid Just Works whenever an input channel is available;
• treat each GATT characteristic as a security decision: who can read it, who can write it, and with what level of authentication;
• never expose stable identifiers (serial numbers, MAC addresses, user identifiers) for free reading;
• build a systematic BLE audit into the development cycle, just like a code review;
• consider the radio environment as always hostile — a sniffer now costs less than 50 euros.

Who is it for?

These two modules are designed for teams dealing with BLE in their products or audits:

• firmware engineers working on BLE stacks (Zephyr, ESP-IDF, Nordic SDK);
• mobile app developers interfacing with BLE devices;
• wireless-focused pentesters;
• IoT product architects, especially in the healthcare, industrial and consumer segments;
• product security managers preparing for CRA and ETSI EN 303 645 compliance.

Prior knowledge of BLE is useful but not essential: the concepts (advertising, GATT, pairing, bonding) are introduced throughout the path.

Available now

These two trainings fit naturally into an IoT/OT upskilling path, whether to strengthen an internal team, prepare for CRA compliance or structure a security-by-design approach.

Learn more: https://dvid.eu
Contact us: https://dvid.eu/#contact
Follow our news: https://www.linkedin.com/company/dvid/