After a connection is encrypted, there may be a reason to switch to a different encryption key. The naive approach — disconnect, re-pair with a new key, reconnect — is disruptive and slow. The Encryption Pause procedure avoids this by suspending encryption temporarily, swapping the key, and then restarting encryption with the new key, all without closing the connection.

The steps are:

1. Run the Encryption Pause procedure — pauses the encrypted mode
2. Both sides exchange the new LTK through their respective hosts
3. Run the Encryption Start procedure (as covered previously) — restarts encryption with the new key

The Encryption Pause + Restart combination is particularly valuable when a connection needs to change its security level dynamically. Here is a concrete scenario:

/* Reading BLE encryption status from BlueZ HCI           */
/* Checks if a specific connection is currently encrypted  */

#include <bluetooth/hci.h>

/* After Encryption Change event (event code 0x08):       */
/* evt_encrypt_change.encrypt values:                     */
/* 0x00 = encryption disabled (paused)                    */
/* 0x01 = AES-128 CCM encryption enabled                  */

typedef struct {
    uint8_t  status;
    uint16_t handle;
    uint8_t  encrypt;  /* 0=off, 1=on */
} __attribute__((packed)) evt_encrypt_change;

/* Monitor encryption events with btmon:                  */
/* sudo btmon | grep -A 5 "Encryption Change"             */

The BLE specification defines many optional features. A device is not required to implement all of them. Two devices that connect may have different sets of capabilities, and they need a way to discover what the other side supports so they do not try to use a feature the peer cannot handle.

The Feature Exchange procedure solves this. It exchanges a FeatureSet bitmap — a 64-bit value where each bit represents one optional feature. The meaning of each bit is different depending on the direction of exchange:

Who can start it: In BLE 4.0, only the Master can initiate the feature exchange after connection is established. BLE 4.1 extended this — the Slave can also initiate using the new LL_SLAVE_FEATURE_REQ PDU.

BLE 4.0 defined only one feature bit (encryption). BLE 4.1 and 4.2 progressively added new feature bits for new capabilities. Understanding this evolution explains why you may encounter devices that do not respond to certain procedures — they simply report that bit as 0.

/* Reading local BLE features via BlueZ HCI */
/* LE Read Local Supported Features: OGF=0x08, OCF=0x0003 */

/* Command line: */
/* hcitool cmd 0x08 0x0003 */
/* Returns 8 bytes of feature flags */

/* Feature bit masks from BlueZ hci.h: */
#define LMP_LE_ENCRYPTION    0x000000000001ULL  /* bit 0: 4.0 */
#define LMP_CONN_PARAM_REQ   0x000000000002ULL  /* bit 1: 4.1 */
#define LMP_EXT_REJECT       0x000000000004ULL  /* bit 2: 4.1 */
#define LMP_SLAVE_FEAT_REQ   0x000000000008ULL  /* bit 3: 4.1 */
#define LMP_LE_PING          0x000000000010ULL  /* bit 4: 4.1 */
#define LMP_LE_DATA_LEN_EXT  0x000000000020ULL  /* bit 5: 4.2 */
#define LMP_LL_PRIVACY       0x000000000040ULL  /* bit 6: 4.2 */
#define LMP_EXT_SCAN_FILTER  0x000000000080ULL  /* bit 7: 4.2 */

/* Check if local controller supports data length extension: */
uint64_t features;
hci_le_read_local_supported_features(sock, &features, 1000);
if (features & LMP_LE_DATA_LEN_EXT)
    printf("Data length extension supported\n");
else
    printf("Data length extension NOT supported (BLE 4.0 device)\n");