Why Bluetooth Module Security Matters in Connected Products
When engineers evaluate a Bluetooth module for a new product, they typically compare power consumption, range, and form factor. Security usually enters the conversation late—often after a prototype is running. That’s a problem, because BLE security architecture is largely determined at the module and firmware selection stage. Retrofitting it is expensive and sometimes impossible without a hardware revision.
This guide covers the security primitives built into modern Bluetooth modules, where real-world deployments go wrong, and what engineering teams should verify before committing to a module and stack.
BLE Security Architecture: What the Spec Provides
Bluetooth Low Energy (BLE) security operates at the Link Layer and Host layers. The core mechanisms are:
- Pairing and bonding: Establishes a shared secret (Long-Term Key, LTK) between devices. Once bonded, subsequent connections use the stored LTK to skip full pairing. Pairing methods range from Just Works (no authentication, vulnerable to MITM) to Numeric Comparison and Passkey Entry (user-verified, MITM-resistant).
- LE Secure Connections (LESC): Introduced in BLE 4.2, uses Elliptic Curve Diffie-Hellman (ECDH) on the P-256 curve for key exchange. Provides forward secrecy, meaning compromising the LTK doesn’t expose past sessions. LESC is now the mandatory-to-support pairing method in BLE 5.0+.
- Privacy / Resolvable Private Addresses (RPA): Devices periodically rotate their advertised MAC address. Only a bonded peer holding the Identity Resolving Key (IRK) can resolve the RPA back to the real identity. Prevents passive tracking by third-party scanners.
- Attribute encryption and signing: GATT characteristics can require an encrypted link or a signed write. The module stack must enforce these permissions at the host layer—this is often where vulnerabilities appear.
Common Security Gaps in Module Deployments
The spec provides the tools; the module vendor’s SDK and your firmware determine whether they’re actually used. The following failures appear repeatedly in security audits of BLE products:
| Vulnerability | Root Cause | Attack Impact |
|---|---|---|
| Just Works pairing in production | Default SDK example code left unchanged | MITM intercepts session key during pairing |
| Unencrypted GATT characteristics | Missing permission flags in GATT table definition | Any scanner can read/write device state |
| Fixed MAC address | Privacy/RPA not enabled | Device location trackable by passive observer |
| Cleartext OTA firmware payload | Custom OTA using GATT without transport encryption | Firmware extracted or replaced with malicious image |
| Hardcoded pairing PIN | Passkey Entry with fixed “000000” | Brute-force in <1 second |
Module Selection: Security-Relevant Criteria
Not all modules give equal access to BLE security features. When evaluating options, check the following against the module’s SDK documentation:
LE Secure Connections Support
Verify the SDK explicitly supports LESC with ECDH key generation on-chip. Some older modules (especially those based on pre-4.2 SoCs) support Legacy Pairing only, which relies on a 128-bit TK exchanged in a way vulnerable to brute force. A module running Nordic nRF52840 or nRF52833 with SoftDevice S140 v6+ fully supports LESC. Silicon Labs EFR32BG22 with Bluetooth 5.3 SDK does as well. Verify explicitly—don’t infer from the BLE version number alone.
Secure Boot and Flash Protection
After deployment, the module’s flash should be locked against unauthorized readback. Nordic modules support Access Port Protection (APPROTECT) that disables the debug interface after production programming. TI CC2340 supports readback protection via TrustZone-M. Confirm the production programming flow in your factory actually enables these protections—they are disabled by default for development convenience.
True Random Number Generator (TRNG)
ECDH key generation and RPA rotation both require a hardware TRNG. Software-only PRNGs seeded from a fixed value (common in early-stage firmware) produce predictable keys. Nordic nRF52 series includes a hardware TRNG with 1 Mbit/s throughput. Check that the SDK uses it—some SDK versions have a configuration flag that accidentally falls back to a software RNG when the TRNG FIFO is empty.
OTA Security
If the product supports firmware updates over BLE, the OTA mechanism must include:
- Transport encryption (link layer or application layer AES-128 minimum)
- Firmware image signature verification (ECDSA or RSA-2048) before applying the image
- Rollback protection to prevent downgrading to a vulnerable firmware version
Nordic DFU (Device Firmware Update) over BLE includes all three when properly configured. Some custom OTA implementations strip these protections for simplicity—review the complete DFU flow before sign-off.
Practical Configuration Checklist
Before releasing a BLE product to production, engineering teams should verify the following at the firmware level:
- □ Pairing mode set to LE Secure Connections; Just Works disabled
- □ All GATT characteristics carrying sensitive data require encrypted link
- □ Privacy / RPA enabled with rotation interval ≤ 15 minutes
- □ Flash readback protection enabled in production programming script
- □ TRNG source confirmed in SDK configuration
- □ OTA payload verified with firmware signature before apply
- □ Passkey / PIN not hardcoded; generated dynamically or provisioned per-device
- □ Debug interface (SWD/JTAG) locked on production units
Testing Security Before Shipment
Tools like Wireshark with the Nordic nRF Sniffer or Ubertooth One let you capture and inspect BLE traffic on the test bench. Run the following scenarios before production:
- Pairing sniff test: Capture a pairing session. If you can see the LTK in the capture, Legacy Pairing is being used instead of LESC.
- Unauthenticated write test: Use an app like nRF Connect to write to all GATT characteristics from an unpaired device. Any successful write to a production characteristic is a bug.
- MAC stability test: Monitor the device’s advertised address over 30 minutes. If the address doesn’t rotate, RPA is not active.
- OTA integrity test: Attempt to apply a corrupted firmware image. The device should reject it and remain on the current firmware.
A Bluetooth module that passes this checklist ships with a security posture that matches the effort engineers put into its RF performance. Security isn’t a feature to add later—it’s a configuration decision made at the first prototype.