The two generations
| LE legacy pairing (4.0/4.1) | LE Secure Connections (4.2+) | |
|---|---|---|
| Key agreement | short temporary key, brute-forceable | ECDH (P-256) |
| Passive eavesdropper on pairing | can recover keys (e.g. crackle) | cannot |
| Recommendation | avoid | require it |
Configure your stack to require Secure Connections only (often called "SC only" or "secure connections only mode") for any device that controls something or carries personal data.
Association models: who can be in the middle?
| Model | Needs | MITM protection |
|---|---|---|
| Just Works | nothing | no |
| Numeric comparison | display + yes/no on both sides | yes |
| Passkey entry | display or keyboard on one side | yes |
| Out of band (OOB) | NFC, QR code, factory secret | yes, if the OOB channel is secure |
Headless sensors often end up with Just Works. It still encrypts the link against passive sniffers when combined with Secure Connections, but an active attacker present during pairing can intercept it.
Practical guidance for IoT products
- Require Secure Connections and bonding for control devices (locks, actuators, medical, anything with user data).
- For headless devices, use OOB (QR code with a per-device secret, or NFC) or a static passkey printed on the device that is unique per unit. Never use one passkey for all units.
- Only allow pairing in a pairing window (button press, first boot) and reject pairing otherwise.
- Protect characteristics with the right security level (encrypted + authenticated), not only "encrypted".
- Add application-layer security for commands (signed/encrypted payloads, nonces against replay). The BLE link is one hop; gateways and phones are others.
- Use privacy (resolvable private addresses) to limit tracking; bonded peers resolve the address with the IRK.