Chapter 11 — Security Manager (SM)
Part 1 of 5 — Introduction · Security in Host · Asymmetrical Architecture · Security Breaches · Four Pairing Methods
11.1 — Introduction
What the Security Manager Does
The Security Manager sits above L2CAP and defines every procedure related to pairing, authentication, and encryption between BLE devices. It becomes active once a link layer connection is established and either side needs security on that connection.
Its responsibilities span three areas:
Generates and stores encryption keys and identity keys. Each device generates and controls its own keys — a distributed approach that avoids a single point of failure.
Generates resolvable private addresses and resolves incoming random addresses back to known device identities. This prevents location tracking.
Runs the pairing procedure to establish trust between two devices. Selects the appropriate pairing method based on each device’s hardware capabilities.
Key length flexibility: The SM supports keys ranging from 56 bits up to 128 bits in 8-bit increments. Devices with limited processing power or relaxed security requirements can use shorter keys. The minimum of 56 bits is enforced — remaining bits are padded with zeros. The requesting profile or application specifies what length it needs.
LE legacy pairing vs LE secure connections: Specifications 4.0 and 4.1 defined the original pairing method — now called LE legacy pairing. Specifications 4.2 introduced LE secure connections, which uses P-256 elliptic curve cryptography to provide significantly stronger protection, especially against offline attacks on the pairing exchange.
11.2 — Security in Host Instead of Controller
Why Key Generation Moved to the Host
Classic BR/EDR Bluetooth handles security in the link manager — the firmware on the controller chip. In BLE, all key generation and distribution logic was moved to the host (the application processor running the software stack). Only the final encryption of data before transmission still happens in the controller.
An LE-only controller does not need the processing power and RAM to run complex key generation algorithms. The chip is simpler and less expensive to manufacture. A basic BLE radio with a link layer state machine is all that is needed.
When a security vulnerability is found or a stronger algorithm is required, only the software on the host needs updating. No controller firmware change, no hardware swap — just a host stack update.
11.3 — Asymmetrical Architecture
The Initiator Does More Work So the Responder Does Less
The SM deliberately places a greater computational burden on the initiating device (typically the phone or PC) and reduces the burden on the responding device (the peripheral sensor or accessory). This is not an accidental consequence — it is a deliberate design goal.
Initiator (e.g. smartphone)
Responder (e.g. key fob / sensor)
11.4 — Security Breaches
Three Threats BLE Security Must Address
Understanding why the SM was designed the way it was requires knowing what threats a BLE device faces in the real world. The SM addresses three distinct attack categories.
11.4.1 — Passive Eavesdropping
A passive eavesdropper simply listens to the radio channel without transmitting anything. There is no way for the two communicating devices to detect this — the attacker is invisible. The attacker needs to be within Bluetooth range, which can be anywhere from 10 metres to 100 metres depending on the TX power of the devices involved.
The most damaging form of passive eavesdropping happens during the pairing exchange. If the attacker captures the pairing traffic in LE legacy pairing (BLE 4.0/4.1), it can recover the temporary key used to generate the session key, then decrypt all past and future traffic on that connection.
LE secure connections (BLE 4.2) fixes this by using ECDH key exchange. Even if an attacker captures the entire pairing exchange, they cannot derive the session key because the Diffie-Hellman protocol makes that computationally infeasible without the private keys that never leave the devices.
11.4.2 — Man-in-the-Middle (MITM) — Active Eavesdropping
An MITM attack is an active threat. A rogue device M positions itself between two devices A and B that want to connect. M intercepts everything A sends, relays a modified or verbatim copy to B, and does the same in the reverse direction. Both A and B believe they have a direct connection to each other — they cannot tell the relay exists.
Because M is in the middle it can do two things: read all traffic in plaintext even if the individual A↔M and M↔B links are encrypted; and inject false data, commands, or firmware into either direction of the connection.
Pairing methods that require user interaction (Passkey Entry, Numeric Comparison) prevent MITM because M cannot intercept the digit that the user physically types or confirms on the screen. A is talking to M but M cannot display the same passkey that A would see if it were directly connected to B.
11.4.3 — Location Tracking
Many BLE devices are carried by people all day — smartwatches, fitness bands, key finders, hearing aids. These devices advertise continuously, and their advertising packets contain the device’s Bluetooth address. Without privacy measures, any receiver within range could log these addresses and build a movement history of the person carrying the device.
BLE counters this with Resolvable Private Addresses (RPAs). The device frequently changes its advertising address to a fresh random value. Only devices that hold the correct Identity Resolution Key (IRK) — typically devices the user has previously paired with — can resolve the rotating address back to the original identity. To everyone else, each new address looks like a completely different device.
Tracker (no IRK): cannot link the three — tracking fails ✓
11.5 — Pairing Methods
Four Methods — Selected Based on Hardware Capabilities
The specific pairing method used for a given session is not configured by the developer — it is determined automatically based on what the two devices physically support (keyboard, display, neither, or an OOB channel). The Security Manager negotiates this in Phase 1 of pairing using the IO Capability field.
Used when at least one device has no display and no keyboard. Neither device shows or enters a passkey. Pairing happens silently in the background. A mono Bluetooth headset is the classic example — it has no screen and no numeric input. Just Works provides encryption but does not defend against MITM attacks during pairing because there is nothing for the user to verify.
Both devices independently compute a 6-digit confirmation value and display it to their respective users. The users compare the numbers on the two screens. If the numbers match, they both press confirm. If they do not match, pairing is aborted. This prevents MITM because an attacking device in the middle cannot compute the same 6-digit value that appears on the legitimate devices.
One device displays a 6-digit numeric passkey and the user types it on the other device. The classic example is pairing a Bluetooth keyboard to a PC — the PC shows “Enter PIN: 123456” on screen, the user types 123456 on the keyboard. A TV remote pairing works the same way. This defends against MITM because an attacker cannot intercept the digit the user physically presses on the keyboard.
Security information is exchanged over a different communication channel that is not Bluetooth LE. NFC is the most common implementation — the user physically taps the two devices together. Because NFC only works at extremely short range (a few centimetres), eavesdropping on an NFC tap is nearly impossible. Security level depends on whether the OOB mechanism itself provides MITM protection.
Chapter 11 Security Manager — 5-Part Series
Next — Security Properties & Cryptographic Functions
Part 2 covers the four security levels the SM provides and all ten cryptographic functions including AES-CMAC and the P-256-based functions introduced in BLE 4.2.