LE Secure Connections — Practical Pairing Walk-Through

Chapter 11 Part 6 · Sections 11.10.2 & 11.11 · Figures 11.14–11.16 · Complete Phase 1/2/3 Trace & Chapter Summary

Side 1Master, NoInputNoOutput

SC=YesBoth sides set

5 stepsPhase 2 ECDH

Phase 3Not used

SEO Keywords:

BLE LE Secure Connections practical pairing BLE SC pairing phase 1 NoInputNoOutput BLE public key exchange ECDH phase 2 BLE DHKey calculation authentication stage 1 2 BLE phase 3 no key distribution BLE chapter 11 security manager summary BlueZ LE secure connections btmon

11.10.2 — LE Secure Connections Practical Example

The Scenario

This walkthrough traces a real-world LE Secure Connections pairing session between two devices called Side 1 and Side 2. Side 1 is the Master and starts the process. The capture begins at Frame #505 with a Pairing Request and completes after the DHKey check exchange in Frame #1160. Phase 3 is intentionally absent because both sides chose not to distribute any long-term keys.

This is the most secure pairing path BLE supports — ECDH-based key exchange means even a complete air capture cannot help an attacker derive the session key.

11.10.2.1 — Pairing Phase 1

Figure 11.14 — Pairing Request from Side 1 (Master)

Side 1 opens Phase 1 by sending a Pairing Request to Side 2. Four points stand out in this capture:

Figure 11.14 — Annotated Pairing Request (Frame #505)

Frame #505 — SMP Pairing Request (Side 1 → Side 2)
IO Capabilities NoInputNoOutput → no display, no keyboard
Secure Connections Pairing Yes (SC bit = 1) ← this is the key 4.2 flag
Keypress Notifications Yes both sides must agree or it won’t be used
Key Distribution No Master will not send any keys in Phase 3

Why IO = NoInputNoOutput with Secure Connections? Because LE Secure Connections with NoInputNoOutput on both sides selects the Just Works association model. The security comes from the ECDH key exchange — no user interaction is needed to protect the key derivation. Contrast this with LE legacy pairing where Just Works is vulnerable because the TK is zero. In SC, the DHKey is computationally protected regardless of the association model.

Figure 11.15 — Pairing Response from Side 2 (Slave)

Side 2 replies with its own capability set. Three observations:

IO Capabilities = KeyboardDisplay — Side 2 actually has a keyboard and display. Despite this, the pairing method remains Just Works because Side 1 is NoInputNoOutput. The weakest IO capability wins.

Secure Connections = Yes — Both sides now have SC=1. This confirms that the Phase 2 exchange will use ECDH and not the legacy TK/STK method.

Keypress Notification = No — Side 1 set this to Yes but Side 2 sets it to No. Since both sides must agree, keypress notifications will not be used in this session.

Key Distribution = No — Side 2 will also not send any keys in Phase 3.

11.10.2.2 — Pairing Phase 2

Figure 11.16 — The ECDH-Based Authentication Exchange

Phase 2 in LE Secure Connections involves five distinct steps. The capture shows all of them between Frames #991 and #1160:

Figure 11.16 — Pairing Phase 2 Complete Sequence

Side 1 (Master) Side 2 (Slave)
Phase 1 complete — both sides know SC=Yes, IO caps exchanged
Step 1 — Public Key Exchange (Frames #991, #1000)
→
Pairing Public Key (Side 1’s 64-byte P-256 public key: Xa, Ya) [Frame #991]
←
Pairing Public Key (Side 2’s 64-byte P-256 public key: Xb, Yb) [Frame #1000]
Step 2 — Each side independently generates a random nonce for use in steps 3-5
Step 3 — Authentication Stage 1 (Frames #1002, #1149, #1154)
←
Pairing Confirm — Side 2’s Cb value using f4(PKa, PKb, Nb, 0) [Frame #1002]
→
Pairing Random — Side 1’s random nonce Na [Frame #1149]
←
Pairing Random — Side 2’s random nonce Nb [Frame #1154]
Step 4 — Each side independently calculates DHKey = P256(own_SK, peer_PK). Same value on both sides.
Step 5 — Authentication Stage 2 (Frames #1155, #1160) — Verification
→
Pairing DHKey Check — Side 1’s Ea using f6(MacKey, Na, Nb, …) [Frame #1155]
←
Pairing DHKey Check — Side 2’s Eb using f6(MacKey, Nb, Na, …) [Frame #1160]
Both DHKey check values verified ✓ → LE Secure Connection established → Link encrypted with LTK

Why does Side 2 send the confirm before Side 1 sends its random? This commit-and-reveal pattern ensures neither side can choose a nonce after seeing the other’s. Side 2 commits to Nb by publishing Cb=f4(PKa, PKb, Nb, 0). Only after this commitment does Side 1 reveal Na. Side 2 then reveals Nb. Side 1 can now verify that Cb was correctly computed using the Nb just received. Neither side can retroactively change their nonce without breaking the commitment.

11.10.2.3 — Pairing Phase 3

Phase 3 Does Not Happen in This Session

Both Side 1 and Side 2 set their Key Distribution fields to No during Phase 1. This means there are no keys to distribute and Phase 3 is completely skipped. The capture jumps directly from the DHKey check exchange to normal encrypted data traffic.

This is a valid configuration. For LE Secure Connections, the LTK was already derived from the DHKey computation — it does not need to be sent over the air as it would in legacy pairing. If both sides are satisfied with session-only security (no long-term bonding), Phase 3 is unnecessary.

Frame sequence summary:
#505Pairing Request (Phase 1 starts)
#845Pairing Response (Phase 1 ends)
#991Pairing Public Key (Side 1’s key)
#1000Pairing Public Key (Side 2’s key)
#1002Pairing Confirm (Slave → Master)
#1149Pairing Random (Master → Slave)
#1154Pairing Random (Slave → Master)
#1155Pairing DHKey Check (Master → Slave)
#1160Pairing DHKey Check (Slave → Master)
#3740Security Request (new session start)
—Phase 3: ABSENT (no key distribution agreed)

/* Monitor LE Secure Connections pairing with btmon           */
sudo btmon

/* Phase 1 — look for SC bit in AuthReq:                     */
/* SMP: Pairing Request (0x01)                               */
/*   IO capability: NoInputNoOutput (0x03)                   */
/*   Authentication requirement: Bonding, SC (0x09)          */
/*                                              ^^            */
/*                                 SC bit = 1 confirmed       */

/* Phase 2 — public key exchange:                            */
/* SMP: Pairing Public Key (0x0C)                            */
/*   X: a1b2c3d4... (32 bytes)                               */
/*   Y: e5f6a7b8... (32 bytes)                               */

/* Phase 2 — authentication stage 2:                         */
/* SMP: Pairing DHKey Check (0x0D)                           */
/*   E: ff112233445566778899aabbccddeeff                      */

/* Encryption starts after DHKey check exchange:             */
/* HCI_LE_Long_Term_Key_Request_Reply sent by host           */
/* Encryption Change Event: handle=64, enabled=1

11.11 — Chapter 11 Summary

What the Security Manager Delivers

The Security Manager handles everything security-related after a Link Layer connection is established. It is placed in the host rather than the controller — keeping the controller simple and the security logic upgradeable through software.

Key design choices

Security in host, not controller
Asymmetrical — phone does heavy work
56–128 bit key lengths in 8-bit steps
RPA privacy for location protection

Three-phase pairing

Phase 1: exchange capabilities & agree method
Phase 2: STK (legacy) or LTK via ECDH (SC)
Phase 3: distribute LTK, EDIV, IRK, CSRK
Phase 3 optional — may be skipped

LE Secure Connections (4.2)

P-256 ECDH — key not exposed over air
LTK derived from DHKey locally
Forward secrecy per session
Replay-resistant with nonce exchange

Next Chapter: Attribute Protocol (ATT) — the read/write/notify mechanism that runs on CID 0x0004. ATT is what every BLE data exchange ultimately relies on and forms the foundation for GATT.

Chapter 11 SM Series

Part 1
Intro & Threats Part 2
Crypto Functions Part 3
Phases 1 & 2 Part 4
SMP Commands Part 5
Legacy Examples

Part 6 ✅
SC Examples & Summary

Next — Chapter 12: Attribute Protocol (ATT)

ATT defines how BLE devices discover, read, write, and get notified about data. It is the engine under every GATT profile.

Next: ATT Introduction →

embeddedpathashala.com

LE Secure Connections ble smp layer