How Does BLE Pairing and Security Work in Embedded Products?

Detailed Explanation

BLE security determines whether an attacker who intercepts radio traffic between your device and a smartphone can read or modify the data — and whether an unauthorised device can connect and issue commands. Getting security right from the start of a design avoids a redesign that requires shipping a firmware update to every deployed unit.

The Security Manager Protocol

BLE security is built on the Security Manager Protocol (SMP), which operates over a dedicated L2CAP channel (CID 0x0006) between the peripheral and central. The SMP defines:

• Pairing — the initial exchange that establishes a shared secret between two previously unassociated devices
• Bonding — optionally persisting the derived long-term keys to flash so future reconnections skip re-pairing
• Encryption — the Link Layer uses AES-CCM to encrypt all subsequent traffic after keys are established

The pairing process produces keys distributed between the devices:

• Long-Term Key (LTK): used to re-encrypt future connections without re-pairing (stored by bonder)
• Identity Resolving Key (IRK): used to resolve private resolvable addresses to the real identity address
• Connection Signature Resolving Key (CSRK): optional; used for signed writes without full encryption

Pairing Methods

The pairing method depends on the input/output capabilities declared by both devices during the Pairing Request / Pairing Response SMP exchange. The combination of capabilities determines which method the Bluetooth stack selects automatically:

Just Works — Neither device performs any authentication check. The peripheral advertises no I/O capabilities (NoInputNoOutput). Key exchange completes without any user confirmation, providing no protection against man-in-the-middle attacks. Appropriate only for products where eavesdropping is a known, accepted risk — for example, a BLE proximity sensor broadcasting non-sensitive public data where encryption is required only for protocol compliance, not data confidentiality.

Passkey Entry — One device displays a 6-digit passkey; the user enters it on the other. Provides MITM protection because an attacker would need to know the passkey to impersonate either device. In Legacy Pairing, the passkey is used in the STK derivation; in LE Secure Connections it is used to authenticate the ECDH key exchange.

Numeric Comparison — Available only with LE Secure Connections. Both devices display a 6-digit number; the user confirms it matches on both. Does not require the user to type anything — just compare and confirm. Provides MITM protection equivalent to Passkey Entry. Requires display output on both devices.

Out-of-Band (OOB) — Keys are exchanged through a channel other than the BLE radio — typically NFC, QR code scanning, or a physical connection. The BLE pairing procedure uses the OOB-exchanged data to authenticate both parties. Provides the strongest MITM protection since the attacker would need to intercept the OOB channel separately.

Legacy Pairing vs LE Secure Connections

Legacy Pairing (BLE 4.0/4.1) uses a Temporary Key (TK) to encrypt the initial STK derivation. The TK is either 0 (Just Works) or the 6-digit Passkey. An attacker who captures the full pairing exchange can recover the STK via an offline brute-force attack on the TK — this takes milliseconds for Just Works (TK = 0) and under a minute for all Passkey values on modern hardware.

LE Secure Connections (LESC) (BLE 4.2+) replaces the TK mechanism with Elliptic Curve Diffie-Hellman (ECDH) on the P-256 curve. Each device generates an ECDH key pair and exchanges public keys. The shared secret derived from ECDH cannot be recovered from captured traffic even if the attacker records the entire pairing exchange — breaking the ECDH requires solving the discrete logarithm problem on P-256, which is computationally infeasible. LESC also provides forward secrecy: capturing old traffic does not help decrypt new sessions.

Use LE Secure Connections for:

• Products transmitting health or medical data
• Products with device access control (locks, actuators)
• Products accepting firmware updates over BLE (OTA)
• Any product where the data has commercial or privacy value

Declare LESC capability in firmware:

Zephyr:

/* In your BLE configuration — add to prj.conf: */
CONFIG_BT_SMP=y
CONFIG_BT_SMP_SC_PAIR_ONLY=y  /* Reject Legacy Pairing; require LESC */

ESP32 NimBLE:

ble_hs_cfg.sm_sc = 1;       /* Enable LE Secure Connections */
ble_hs_cfg.sm_mitm = 1;     /* Require MITM protection       */

Bonding: Persisting Keys for Reconnection

Without bonding, the full pairing exchange (including any user interaction) repeats every connection. With bonding enabled, the peripheral and central store the LTK and IRK in non-volatile memory after the first pairing — subsequent connections resume encryption automatically.

Bonding flow:

1. Initial pairing completes; LTK and IRK are distributed
2. Both devices store keys in persistent flash
3. On reconnect, the central sends an LL_START_ENC_REQ with the stored LTK and a random nonce
4. The peripheral confirms it holds the matching LTK; encryption resumes without SMP
5. No user interaction required for reconnection

Enabling bonding in Zephyr:

/* In prj.conf: */
CONFIG_BT_BONDABLE=y
CONFIG_BT_SETTINGS=y        /* Required for persistent key storage  */
CONFIG_SETTINGS_RUNTIME=n   /* Set to y if using runtime settings   */

/* In application code — pair callback: */
static void auth_pairing_complete(struct bt_conn *conn, bool bonded)
{
    if (bonded) {
        /* Keys stored in settings flash partition automatically */
    }
}
static struct bt_conn_auth_info_cb auth_info_cb = {
    .pairing_complete = auth_pairing_complete,
};
bt_conn_auth_info_cb_register(&auth_info_cb);

Enabling bonding in ESP32 NimBLE:

ble_hs_cfg.sm_bonding = 1;            /* Request bonding during pairing */
ble_hs_cfg.sm_our_key_dist = BLE_SM_PAIR_KEY_DIST_ENC | BLE_SM_PAIR_KEY_DIST_ID;
ble_hs_cfg.sm_their_key_dist = BLE_SM_PAIR_KEY_DIST_ENC | BLE_SM_PAIR_KEY_DIST_ID;

NimBLE persists bonds in NVS via nvs_flash_init() — ensure the NVS partition is initialised before the BLE stack starts.

Security Modes and Levels

The Bluetooth specification defines security requirements that can be applied per-characteristic in the GATT table:

For most IoT products, Mode 1 Level 3 (authenticated + encrypted) is the minimum appropriate level for characteristics that control the device or read private data. Mode 1 Level 4 (LESC) is required for products under medical or financial data regulations. Assign security levels per-characteristic in the GATT service definition:

Zephyr:

/* Example: write requires authenticated pairing */
BT_GATT_CHARACTERISTIC(&config_uuid, BT_GATT_CHRC_WRITE,
    BT_GATT_PERM_WRITE_AUTHEN,   /* Level 3: authenticated */
    NULL, write_handler, NULL),

Private Addresses and Identity

A BLE device using a static or public Bluetooth address can be tracked across sessions — any passive Bluetooth scanner sees the same address in every advertising packet. To prevent tracking, enable Resolvable Private Addresses (RPA):

• The device generates a new private address periodically (typically every 15 minutes per Bluetooth specification default)
• The address contains a hash computed from the IRK, making it resolvable only by bonded devices holding the IRK
• Unbonded scanners see only random-looking addresses; bonded centrals resolve the address to the known identity

Zephyr:

/* Enable privacy / RPA in prj.conf: */
CONFIG_BT_PRIVACY=y
CONFIG_BT_RPA_TIMEOUT=900    /* 15 minutes between address rotations */

Design Considerations

• Choose the pairing method before designing the hardware: Passkey Entry requires the peripheral to have either a display or a keyboard (or both). Numeric Comparison requires a display. If the product has no I/O (no display, no buttons), Just Works is the only option without OOB — plan the hardware to enable the appropriate security level for the application.
• Test the pairing flow on iOS and Android separately: iOS prompts the user with a pairing dialog; the app cannot initiate or control the dialog. Android gives the app more control via BluetoothDevice.createBond(). The UX differs significantly — design and test both paths.
• Store bonding data in a dedicated flash partition: on nRF52 with Zephyr, bonding data is stored via the Settings subsystem in a dedicated flash area defined in the partition table. Size it for the maximum number of bonds you want to support (each bond entry is approximately 200 bytes).
• Bond limit management: embedded peripherals have limited flash for bond storage. Implement a bond management strategy: most-recently-used eviction when the bond table is full, or an explicit "forget all bonds" button. Failing to handle a full bond table silently rejects new pairings.
• OTA security: if the product supports OTA firmware updates over BLE, encrypt the channel at Level 3 or Level 4 before accepting firmware data. A BLE OTA endpoint with no security is a remote code execution vector.
• Zeus Design develops secure BLE firmware and paired mobile applications for IoT products, covering pairing UI flows, GATT security level assignment, and bonding database management on both embedded and mobile platforms.

Common Mistakes

• Shipping a product with Just Works pairing for sensitive data: Just Works provides no MITM protection and no resistance to eavesdropping in Legacy Pairing mode. Any product that transmits health readings, access credentials, or configuration data must use at minimum Passkey Entry with Legacy Pairing, and ideally LE Secure Connections.
• Enabling bonding without persistent storage: bonding without CONFIG_BT_SETTINGS=y (Zephyr) or NVS initialisation (NimBLE) stores keys only in RAM — they are lost on every power cycle, forcing re-pairing on every boot. Users experience this as "the device keeps forgetting my phone."
• Not clearing stale bonds after a factory reset: if a firmware update or factory reset clears application flash but not the bonding partition, the device holds bonds that no longer match any central's records. The device refuses new pairings with different centrals (bond table full), and the registered central fails to reconnect (LTK mismatch). Clear the settings/NVS partition explicitly on factory reset.
• Mixing LESC and Legacy Pairing assumptions: CONFIG_BT_SMP_SC_PAIR_ONLY=y rejects Legacy Pairing entirely — any central that does not support LESC (older Android phones or Windows 7/8 hosts) will fail to pair. Verify target platform LESC support before enforcing it; most iOS (iOS 9.3+) and Android (6.0+) devices support LESC.
• Setting the same passkey in every unit: a fixed passkey (hardcoded to 123456 or 000000) across all production units is equivalent to Just Works — an attacker who knows the passkey can pair with any unit. Generate passkeys dynamically if displaying them on a screen, or use OOB (QR code on the device label) for factory floor pairing.
• Ignoring the authentication callback: if the application does not register bt_conn_auth_cb (Zephyr) or set ble_hs_cfg.sm_io_cap (NimBLE) before pairing begins, the stack defaults to NoInputNoOutput → Just Works, regardless of the hardware's actual I/O capability. Register auth callbacks before the first connection is established.