GAP Security — Modes, Procedures, Privacy & Random Addresses
Chapter 14 · Sections 14.6.4.3–14.8 · Bonding · LE Security Modes 1 & 2 · Data Signing · Privacy Feature · Random Device Address · Chapter 14 Summary
14.6.4.3 — Bonding Procedure Optional — Peripheral & Central
Storing Security Keys for Future Reconnections
Bonding is triggered when a service on the peer device requires it. The Security Manager of the Central initiates pairing. If both sides are in Bondable Mode, they complete the SM pairing procedure (Chapter 11) and write the resulting keys into their persistent security databases so future connections can re-encrypt without repeating the full pairing exchange.
/* View bonded device security database in BlueZ: */
cat /var/lib/bluetooth/AA:BB:CC:DD:EE:FF/11:22:33:44:55:66/info
/* [LongTermKey] */
/* Key=aabbccdd11223344aabbccdd11223344 */
/* Authenticated=1 (1=MITM protected, 0=Just Works) */
/* EncSize=16 */
/* Bond a device via btmgmt (LE transport = -t 1): */
sudo btmgmt pair -t 1 11:22:33:44:55:6614.7 — Security Overview
Security is optional for LE devices — implemented only when services need to be protected. After connection, each device’s Security Manager specifies the mode for all subsequent transactions. Requirements can apply at device level or per individual service.
- LE Security Mode 1 — encryption
- LE Security Mode 2 — data signing
- Authentication Procedure
- Authorization Procedure
- Connection Data Signing
- Authenticate Signed Data
14.7.1 — LE Security Mode 1 Encryption-Based
Four Levels of Increasing Protection
Mode 1 covers all encryption-based security in BLE. Each level satisfies all requirements of the levels below it. A Level 3 or Level 4 connection also satisfies LE Security Mode 2 requirements.
14.7.2 — LE Security Mode 2 Data Signing
PDU-Level Integrity Without Link Encryption
Mode 2 signs each PDU with a CSRK-based 12-byte signature instead of encrypting the whole link. This avoids the latency and battery cost of encryption handshakes while still verifying the sender’s identity and protecting against tampering. Data signing is skipped entirely when the connection is already in Mode 1 Levels 2, 3, or 4.
14.7.3 — Secure Connections-Only Mode
No Legacy Pairing Accepted — Level 4 or Nothing
A device in this mode allows only LE Security Mode 1 Level 4 (authenticated LE Secure Connections with encryption) or services that have no security requirement (Level 1). Every legacy pairing attempt is rejected. This mode suits medical devices, payment terminals, and industrial controllers where accepting weaker pairing is not permissible.
/* Enable Secure Connections Only mode with btmgmt: */
sudo btmgmt sc-only on
/* Any Pairing Request with SC bit = 0 is now rejected */
/* Error returned: SMP_AUTH_REQUIREMENTS (0x03) */
/* Verify the flag is set: */
sudo btmgmt info | grep -i "secure connections"14.7.4 — Authentication Procedure
Checking and Upgrading Security Before Service Access
Authentication covers Mode 1 and is initiated after a connection is established. Authentication is achieved through encryption — the security of that encryption depends on what pairing method was used. Two pairing types are defined:
- Authenticated pairing — pairing was done with MITM protection (Passkey Entry or OOB)
- Unauthenticated pairing — pairing was done with no MITM protection (Just Works)
14.7.5 — Authorization Procedure
A user-confirmation gate above authentication. Even after successful authentication, a device may require the user to explicitly approve access to a specific service. The user actively confirms before the operation is permitted. This is an application-level decision, separate from the pairing state of the connection.
14.7.6 — Encryption Procedure
Slave initiates: Slave sends a Security Request to the Master asking it to start encryption. (Explained in Chapter 11.)
Master initiates: Master directly starts the encrypted session using a stored LTK or by performing fresh pairing.
BLE 4.2 rule: If encryption fails and any device is using a Resolvable Private Address, that address must be discarded immediately and a new one generated.
14.7.7 — Data Signing
12-Byte CSRK Signature — Fast Authenticated Transfers Without Encryption
Data signing is used in Mode 2 when fast connection setup and data transfer are more important than link confidentiality. The sender appends a 12-byte authentication signature to the data PDU using the Connection Data Signing Procedure. The receiver verifies it using the Authenticate Signed Data Procedure. Encrypting an entire link takes time and battery — signing individual PDUs is much cheaper.
/* Data signing uses ATT opcode 0xD2 (Signed Write Command) */
/* PDU = Opcode(1) + Handle(2) + Value(n) + Signature(12) */
/* Signature = 4-byte counter + 8-byte AES-CMAC(CSRK, data) */
/* Counter prevents replay of captured signed PDUs */
/* CSRK stored in BlueZ bonding info: */
grep -A2 SignatureKey \
/var/lib/bluetooth/AA:BB:CC:DD:EE:FF/11:22:33:44:55:66/info
/* [LocalSignatureKey] → our CSRK, distributed to peer */
/* [RemoteSignatureKey] → peer CSRK, used to verify their PDUs */14.7.8 — Privacy Feature
Rotating Addresses to Block Passive Location Tracking
Many LE devices are worn on the body — watches, fitness bands, heart rate monitors, medical patches. A fixed Bluetooth address allows any receiver to track that person’s location by correlating transmissions at different physical points over time. The privacy feature prevents this by changing the device’s advertised address frequently.
A Peripheral supporting privacy exposes two characteristics in its GAP service:
/* Enable privacy (Resolvable Private Address) in BlueZ: */
sudo btmgmt privacy on
/* Configure RPA rotation interval (default 15 minutes): */
/* /etc/bluetooth/main.conf */
/* [Policy] */
/* PrivacyTimeout = 900 # seconds */
/* View IRK stored for a bonded device: */
grep -A2 IdentityResolvingKey \
/var/lib/bluetooth/AA:BB:CC:DD:EE:FF/11:22:33:44:55:66/info
/* Key=aabb... ← IRK used to resolve this device's RPA */
/* BlueZ loads IRKs into Controller resolving list (4.2+) */
/* See hci_sync.c: hci_le_add_device_to_resolving_list_sync() */14.7.9 — Random Device Address Types
Four Leaves on the Address Type Tree
GAP defines the complete taxonomy of LE device addresses. A device can use either its permanent public address or one of three types of random address.
/* Enable RPA rotation in BlueZ: */
sudo btmgmt privacy on && sudo btmgmt power on
/* btmon shows current RPA being used: */
sudo btmon 2>&1 | grep "Random Address"
/* Random Address: 5d:a2:f1:xx:xx:xx (type: resolvable) */
/* BlueZ automatically adds bonded device IRKs to */
/* the Controller resolving list (BLE 4.2+ hardware): */
/* hci_le_add_device_to_resolving_list_sync() in hci_sync.c */
/* This allows Controller-side RPA resolution without */
/* host wakeup for every advertising event */14.8 — Chapter 14 Summary
What GAP Delivers Across the Stack
The Generic Access Profile is the bedrock every BLE device stands on. It defines the minimum protocol stack, the exact terminology for user interfaces, the structure of advertising data, how devices discover each other, how connections are made and terminated, and how all levels of security are applied. It also ensures consistent naming conventions between LE and BR/EDR — so “Bluetooth Device Name” and “Bluetooth Passkey” mean the same thing to users regardless of the underlying transport.