SM Part 3 — Pairing: Phases 1 & 2
Chapter 11 Part 3 of 5 — Three-Phase Overview · IO Capability · OOB · Key Size · Repeated Attempts · Phase 2 All Methods · LE SC ECDH
11.8 — Pairing Overview
Three Phases — Two Mandatory, One Optional
Pairing establishes the cryptographic keys needed to encrypt the link. It always starts with a feature exchange to decide what each device can do, then runs an authentication procedure to generate a session key, and optionally distributes long-term keys for future reconnections.
Phases 1 and 2 can run on an unencrypted link. Phase 3 must run on an encrypted link — the keys being distributed in Phase 3 are sensitive, so they must already be protected before distribution begins. The STK generated in Phase 2 provides that protection.
11.8.1 — Phase 1: Pairing Feature Exchange
Everything Both Sides Need to Know Before Pairing Can Start
The Initiator (Master) always starts Phase 1 by sending a Pairing Request. The Responder (Slave) replies with a Pairing Response. After this one-round-trip exchange, both devices know exactly what the other supports and can deterministically select a pairing method for Phase 2 without further negotiation.
11.8.1.1 — IO Capability
The IO Capability field tells the peer what input and output hardware this device has. The combination of both devices’ IO capabilities determines which pairing method Phase 2 will use.
Input capabilities — three options:
Output capabilities — two options:
| Input Capability | No Output | Numeric Output |
|---|---|---|
| No Input | NoInputNoOutput | DisplayOnly |
| Yes / No | NoInputNoOutput | DisplayYesNo |
| Keyboard | KeyboardOnly | KeyboardDisplay |
11.8.1.2 — OOB Authentication Data
A device sets the OOB flag if it has an out-of-band channel available for authentication data. The most common OOB mechanism is NFC — the user taps the two devices together to exchange authentication material. Because NFC only works at a few centimetres, an attacker cannot intercept this exchange without being physically present.
OOB provides stronger security than keyboard/display methods because the authentication material never travels over Bluetooth at all. The OOB flag in the Pairing Request tells the peer whether this device’s OOB data is available and should be used.
11.8.1.3 — Encryption Key Size
Both devices state their maximum supported encryption key length. Valid range: 7 octets (56 bits) minimum to 16 octets (128 bits) maximum. During Phase 1 both values are exchanged, and the lesser of the two is used for the session. This ensures compatibility — a high-end device connecting to a resource-constrained sensor will use the sensor’s supported key length.
Maximum — full AES-128
Minimum — 7 octets
56, 64, 72, 80…128
Keys shorter than 128 bits have their high-order bytes set to zero. This keeps the implementation uniform — all functions always operate on 128-bit values, but some bits are predetermined zeros.
11.8.1.4 — Repeated Attempts Protection
If a pairing attempt fails — wrong passkey, confirm value mismatch, or deliberate abort — the responding device does not allow another immediate attempt. It starts a waiting timer whose value doubles with each consecutive failure. This exponential backoff makes brute-force attacks on the pairing process impractical.
11.8.2 — Phase 2: Authentication and Encryption
Method Selection Rules
After Phase 1, both devices pick the pairing method for Phase 2 using a deterministic set of rules. The same rules are applied independently by both sides — they must reach the same conclusion:
Key types generated: LE legacy pairing generates two keys — a Temporary Key (TK) and a Short Term Key (STK). The STK encrypts the link at the end of Phase 2. LE secure connections skips the temporary key entirely and directly generates the Long Term Key (LTK) via ECDH.
11.8.2.1 — Just Works
The TK is set to zero by both sides. This is the “no user interaction” path — pairing completes without showing or entering any value. After Phase 2 completes, the link is encrypted, so data is protected from passive listeners. MITM protection does not exist — an attacker present during pairing could intercept the exchange since TK=0 is trivially known.
11.8.2.2 — Numeric Comparison (LE Secure Connections Only)
Both devices independently compute a 6-digit value using the g2 function (covered in Part 2). Both display their result. The user reads both displays and confirms they match by pressing “yes” on both devices. Pairing aborts if they do not match or if the user declines.
11.8.2.3 — Passkey Entry
One device has a display, the other has a keyboard. The TK is the displayed 6-digit number (0–999999). The passkey is shown on the display device and the user types it on the keyboard device. Both devices compute the STK using this TK. MITM protection comes from the fact that the user’s physical typing action cannot be intercepted remotely.
11.8.2.4 — Out of Band (OOB)
Both devices must have the OOB Authentication Data flag set. Security level depends entirely on the security of the OOB mechanism. NFC provides strong protection due to physical proximity requirements. If the OOB mechanism provides MITM protection, then MITM protection is achieved for the pairing.
11.8.2.5 — LE Secure Connections Phase 2 — Full ECDH Flow
LE Secure Connections Phase 2 is significantly more complex than legacy Phase 2 but provides much stronger security guarantees. Figure 11.5 in the textbook shows the full sequence:
/* BlueZ SM layer handles LE Secure Connections automatically */
/* To check if both sides support SC before pairing: */
/* Read LE local features — bit 6 = LL Privacy, not SC */
/* SC support is indicated by the SC bit in SMP Pairing Req */
/* (AuthReq byte, bit 3 = SC flag, introduced in BLE 4.2) */
/* With bluetoothctl — SC is negotiated automatically: */
/* [bluetooth]# pair AA:BB:CC:DD:EE:FF */
/* If both support SC, you may see Numeric Comparison prompt: */
/* Confirm passkey 384291 (yes/no): yes */
/* With btmon, SC pairing shows: */
/* SMP: Pairing Request (0x01) */
/* IO capability: DisplayYesNo */
/* Authentication requirement: Bonding, MITM, SC, Keypress */
/* ^^ */
/* SC bit set = 4.2 mode */Chapter 11 Security Manager — 5-Part Series
Next — Phase 3 Key Distribution & SMP Protocol Commands
Part 4 covers Phase 3 key distribution (LTK, EDIV, IRK, CSRK) with each key’s purpose and bit width, the SMP command format (Figure 11.6), the full Table 11.2 of command codes, and the Phase 1/2/3 signaling commands with Figure 11.7–11.10.