The Provisioning Problem
Device provisioning is where most BLE security vulnerabilities appear. Default pairings, hardcoded keys, and unencrypted characteristic writes are common mistakes.
Pairing Modes
- Just Works — No authentication. Never use for security-sensitive provisioning.
- LE Secure Connections — Elliptic curve Diffie-Hellman. Use this. Available in BLE 4.2+.
- OOB (Out-of-Band) — Exchange keys via NFC or QR code. Best security for provisioning.
Zephyr Implementation
static const struct bt_conn_auth_cb auth_cb = {
.passkey_display = auth_passkey_display,
.passkey_confirm = auth_passkey_confirm,
};
bt_conn_auth_cb_register(&auth_cb);
/* BT_SECURITY_L4 = authenticated LE Secure Connections + encryption */
bt_conn_set_security(conn, BT_SECURITY_L4);Common Vulnerabilities to Avoid
- Fixed passkeys — Never hardcode 123456. Generate per-device from UID.
- Unencrypted OTA — Always require BT_SECURITY_L2 minimum before DFU writes.
- No bonding expiry — Implement bond revocation on factory reset.
- Advertising personal data — Rotate MAC address with CONFIG_BT_PRIVACY=y.