BLE Pairing Security Workbench

Step through BLE pairing, IO capability selection, LE Secure Connections key exchange, authentication, and encrypted link setup.

animation
bluetooth
ble
security
pairing
short-range
Interactive BLE pairing animation showing Security Manager feature exchange, IO capability method selection, LE Secure Connections P-256 ECDH, Just Works, Passkey Entry, Numeric Comparison, OOB authentication, LTK generation, and encrypted GATT access.
Animation BLE Security SMP Pairing LE Secure Connections

BLE Pairing Security Workbench

Follow the Security Manager conversation that turns a first BLE connection into an encrypted link. Change IO capabilities, pairing method, and protocol generation to see why the same devices may end up with Just Works, Passkey Entry, Numeric Comparison, or OOB authentication.

Selected Method Numeric Comparison
Key Agreement P-256 ECDH
MITM Result Protected
Encryption Key 128-bit LTK
1

Exchange Features

Pairing starts by comparing IO capabilities, authentication flags, Secure Connections support, and key size.

2

Choose Association

The selected method depends on the two devices. No display or keyboard usually means Just Works.

3

Prove The Peer

Passkey, Numeric Comparison, and suitable OOB data add a user-verifiable step that blocks simple MITM attacks.

4

Encrypt And Bond

LE Secure Connections derives a 128-bit LTK from the ECDH result and can store keys for later reconnection.

Pairing Exchange Animation

Step through the SMP flow. The moving packet, device labels, timeline, and diagnosis all update together.

learner-ready
BLE pairing sequence between central and peripheral A phone central and a sensor peripheral exchange pairing messages while an optional attacker shows whether the selected method resists man-in-the-middle attacks. Central DisplayYesNo Peripheral DisplayYesNo MITM radio range PK LE Secure Connections Numeric Comparison Authenticated encryption
Phase 1 of 6 Pairing Feature Exchange

Devices exchange IO capabilities, MITM preference, Secure Connections support, bonding request, and maximum encryption key size.

1. Features
2. Public keys
3. Authentication
4. Checks
5. LTK and encryption
6. Bonded GATT
Current phase Pairing Feature Exchange

Feature flags choose what can be secured.

Security decision Authenticated encryption

The selected method gives user-verifiable MITM protection.

Feature exchange: IO capabilities and authentication flags decide the available methods.
Key exchange: LE Secure Connections exchanges P-256 public keys before deriving a DHKey.
Authentication: User-visible proof turns encryption into peer-authenticated encryption.

Controls And Diagnosis

Use scenarios first, then override IO capabilities to test edge cases.

Association Model Numeric Comparison
Passive Eavesdropping Protected by ECDH
MITM Attack Blocked
Bonding Outcome Reusable LTK stored
SC flag on 128-bit LTK MITM protected

BLE Pairing Quick Reference

SMPairing

Pairing creates the keys and security properties needed for an encrypted LE link. Bonding stores those keys for future reconnections.

IOCapabilities

Display, keyboard, yes/no, and OOB support determine which association model is possible. NoInputNoOutput usually forces Just Works.

JWJust Works

Convenient and common for simple devices, but unauthenticated. It encrypts traffic after pairing but does not prove the peer to the user.

PKPasskey Entry

A six-digit value is displayed, entered, or entered by both users. In LE Secure Connections it provides authenticated MITM protection.

NCNumeric Comparison

LE Secure Connections only. Both sides display the same six-digit value and the user confirms that they match.

OOBOut Of Band

Authentication data arrives through a separate channel such as NFC, QR, wired setup, or provisioning. Security depends on that channel.

DHP-256 ECDH

LE Secure Connections exchanges public keys and derives a shared DHKey without sending a private key over the radio link.

LTKEncrypted Link

The Long Term Key is 128 bits and is used to start encryption for the current connection and later bonded sessions.

Learning Support

What To Watch

  1. Start with the default smart lock scenario and press Step once per phase.
  2. Change the peripheral IO to NoInputNoOutput and notice how the method downgrades.
  3. Switch from LE Secure Connections to Legacy to see why the page warns about weaker legacy security.
  4. Turn on OOB and treat the separate channel as the trusted proof.

Method Selection Rules

The full Bluetooth tables are detailed. This workbench keeps the learner-facing cases explicit:

  • Numeric Comparison requires LE Secure Connections and devices that can display and confirm.
  • Passkey Entry requires a display somewhere and keyboard-style input somewhere.
  • Just Works is selected when user verification is not possible.
  • OOB is selected only when an external channel is intentionally used.

Security Interpretation

Encryption and authentication are different outcomes. A Just Works link can become encrypted but still fail to prove that the peer is the intended device.

Technical notes
  • LE Secure Connections uses the P-256 elliptic curve for key agreement.
  • The LTK used for LE Secure Connections encryption is 128 bits.
  • Current Bluetooth Core 6.3 wording ties LE Secure Connections MITM protection to Passkey Entry, Numeric Comparison, or suitable OOB authentication.
  • This animation uses labels and staged packets, not real cryptographic values.

Common Design Mistakes

  • Assuming bonding fixes a weak first pairing. It stores the security result that was achieved.
  • Using NoInputNoOutput for products that protect sensitive data and then accepting Just Works.
  • Showing a passkey but not giving the other device a trustworthy way to enter or confirm it.
  • Forgetting to require the intended GATT security level before exposing sensitive characteristics.