SM Part 4 — Phase 3 Keys & SMP Commands
Chapter 11 Part 4 of 5 — LTK · EDIV · IRK · CSRK · SMP Format · Table 11.2 · Phase 1/2/3 Command Details
11.8.3 — Phase 3: Transport Specific Key Distribution
Optional Phase — Only on Encrypted Links
Phase 3 is optional. It runs only if both devices agreed to distribute keys during Phase 1 (via the Key Distribution fields in the Pairing Request and Response). It always runs on an already-encrypted link — the STK from Phase 2 protects the keys being distributed.
Direction: Keys are distributed first from Slave to Master, then from Master to Slave, following the sequence in Figure 11.10. Only the keys that were negotiated in Phase 1 are actually sent — if the EncKey bit was not set, the LTK is not sent.
11.8.3.1 — Long Term Key (LTK) — 128 bits
The LTK is what the host passes down to the controller when it needs to start or resume an encrypted connection. Both Master and Slave sides have an LTK — they are not the same key; each device stores the key that the other device distributed to it.
For LE legacy pairing, the controller uses the combination of LTK + EDIV + Rand to identify which key to use (there may be multiple bonded devices with different LTKs). For LE secure connections, only the LTK is needed since the DHKey computation produces a unique LTK per session.
11.8.3.2 — EDIV (16-bit) and Rand (64-bit)
These two values are only used in LE legacy pairing. Together they act as an index into the device’s LTK database — when the Master wants to reconnect and sends an encryption request, it provides the EDIV and Rand it received during pairing. The Slave uses these to look up the correct LTK from its stored bonding information.
11.8.3.3 — Identity Resolution Key (IRK) — 128 bits
The IRK is what enables the Resolvable Private Address (RPA) system to work. When a device uses RPAs, its advertising address changes every 15 minutes. The IRK is the secret that links all those rotating addresses to the same real identity.
How it works: To generate an RPA, the device takes a random 22-bit number (prand), runs it through the ah function (which uses the IRK as the key), and produces a 24-bit hash. The RPA = prand || hash. Any device with the IRK can reproduce the hash from the prand and verify the address belongs to the known bonded device. Without the IRK, the address looks completely random.
Distribution direction matters: When Device A distributes its IRK to Device B, Device B can now resolve Device A’s future RPAs. And vice versa. After Phase 3, both devices can silently recognise each other’s advertising even when they are using rotating private addresses — but strangers cannot track either device.
11.8.3.4 — Connection Signature Resolving Key (CSRK) — 128 bits
BLE has a data signing feature where a device can attach a 12-octet signature to its data PDUs. The receiving device verifies the signature to confirm the data came from the expected source and has not been tampered with. This provides data origin authentication without requiring a full encrypted connection.
The CSRK is what makes this work — it is the 128-bit key used to generate and verify those 12-octet signatures. A different CSRK is used for each peer device. When Device A distributes its CSRK to Device B, Device B can verify signed data from Device A. Device A uses a counter value that it increments with every signed PDU — this prevents replay attacks.
/* Keys in the BlueZ bonding database */
/* Location: /var/lib/bluetooth/[adapter_addr]/ */
/* [device_addr]/info */
/* Example bonding info file content: */
/* [LongTermKey] */
/* Key=A1B2C3D4E5F6... (32 hex chars = 128-bit LTK) */
/* Authenticated=1 */
/* EncSize=16 */
/* EDiv=0x1234 (EDIV, legacy pairing only) */
/* Rand=0x... (Rand, 8 bytes hex, legacy pairing only) */
/* */
/* [IdentityResolvingKey] */
/* Key=F1E2D3C4... (128-bit IRK) */
/* */
/* [LocalSignatureKey] */
/* Key=00112233... (128-bit CSRK) */
/* Counter=0 */
/* */
/* [RemoteSignatureKey] */
/* Key=AABBCCDD... (peer's CSRK) */
/* Counter=0 */11.9 — Security Manager Protocol
CID 0x0006 — Every SMP Command Uses the Same Channel
All SMP commands travel over L2CAP CID 0x0006 — the fixed Security Manager channel that we saw in Chapter 10. This channel requires no setup — it is available immediately after the Link Layer connection is established.
30-second timer: A single 30-second watchdog timer covers all SMP procedures. If any step in the pairing process takes longer than 30 seconds (perhaps because the user is slow to enter a passkey), the procedure is considered failed and the higher layers are notified. If the application wants to retry, a new physical connection must be established first.
Table 11.2 — Complete SMP Command Code Reference
| Code | Description | Phase |
|---|---|---|
| 0x00 | Reserved | — |
| 0x01 | Pairing Request | Phase 1 |
| 0x02 | Pairing Response | Phase 1 |
| 0x03 | Pairing Confirm | Phase 2 |
| 0x04 | Pairing Random | Phase 2 |
| 0x05 | Pairing Failed | Phase 2 |
| 0x06 | Encryption Information | Phase 3 |
| 0x07 | Master Identification | Phase 3 |
| 0x08 | Identity Information | Phase 3 |
| 0x09 | Identity Address Information | Phase 3 |
| 0x0A | Signing Information | Phase 3 |
| 0x0B | Security Request | Phase 1 (Slave initiates) |
| 0x0C | Pairing Public Key (4.2) | Phase 2 |
| 0x0D | Pairing DHKey Check (4.2) | Phase 2 |
| 0x0E | Pairing Keypress Notification (4.2) | Phase 2 |
| 0x0F–0xFF | Reserved | — |
11.9.1 — Phase 1 Commands
Figure 11.7 — Sequence of Phase 1 Commands
If the Slave needs an encrypted link before it will serve data (for example, a Glucose meter that only sends readings after bonding), it sends this command. The Master may respond with a Pairing Request, or it may ignore the Security Request if it decides encryption is not needed right now.
The Initiator sends its full capabilities in this command. The fields include:
1 bit
1 bit
1 bit
5 bits
Same fields as Pairing Request. The Responder confirms which key distribution bits it will honour. If the Master set any distribution bit to zero, the Slave cannot set it to one (it cannot offer more than what was asked). Once both commands complete, both devices have identical knowledge of which keys will be exchanged and which pairing method Phase 2 will use.
11.9.2 — Phase 2 Commands
Legacy Pairing — Confirm/Random Exchange (Figure 11.9)
Both devices send their confirm value without yet revealing the random nonce they used to compute it. This commit-and-reveal pattern ensures neither side can choose their nonce after seeing the other side’s nonce.
After both confirm values have been exchanged, each side reveals their random number. The receiver recalculates the confirm value using the received random and checks it against the previously received confirm. If they match, the other side is genuine.
Sent when any check fails — confirm value mismatch, unsupported feature, or passkey entered incorrectly. Carries a reason code. Triggers the Repeated Attempts backoff timer on the receiving device.
4.2
Used in LE Secure Connections Phase 2. Both the initiator and responder use this command to send their 64-byte P-256 public key to the peer. The public key is split into two 32-byte coordinates: X and Y. The private key never leaves the device.
4.2
Carries the 128-bit check value computed by f6 using the MacKey (from f5). Both devices send this to each other. If both check values verify correctly, the entire Secure Connections exchange is confirmed as genuine and the LTK is accepted for link encryption.
4.2
Used only when the Passkey Entry method is active and only by the device with KeyboardOnly IO capability. Informs the display device what the user is doing: passkey entry started, digit entered, digit erased, cleared, or completed. This allows the display device to show a visual indicator (e.g. a fill-in bar) of entry progress.
11.9.3 — Phase 3 Commands
Five commands distribute the long-term keys. All five are only sent after the link is encrypted with the STK from Phase 2.
/* Monitoring SMP pairing with btmon: */
/* sudo btmon | grep -A 20 "SMP:" */
/* You will see: */
/* SMP: Pairing Request (0x01) */
/* IO capability: DisplayYesNo (0x01) */
/* OOB data: Authentication data not present */
/* Authentication requirement: Bonding, MITM, SC (0x0d) */
/* SMP: Pairing Response (0x02) */
/* IO capability: NoInputNoOutput (0x03) */
/* SMP: Pairing Confirm (0x03) */
/* SMP: Pairing Random (0x04) */
/* SMP: Encryption Information (0x06) [Phase 3] */
/* Long term key: a1b2c3d4e5f6... */
/* SMP: Master Identification (0x07) */
/* EDIV: 0x1234 Rand: 0x1234abcd5678... */
/* SMP: Identity Information (0x08) */
/* Identity resolving key: f1e2d3c4... */Chapter 11 Security Manager — 5-Part Series
Next — Practical Sniffer Examples & Chapter 11 Summary
Part 5 covers the annotated air log captures from real LE legacy pairing sessions (Figures 11.11–11.13) and the LE Secure Connections session setup.