Try — Exchange Features
Pairing starts by comparing IO capabilities, authentication flags, Secure Connections support, and key size.
BLE Pairing Security Workbench
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.
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
Try
Choose device I/O capabilities, security generation, and pairing method for the threat context.
Observe
Step through feature exchange, association, key generation, and encrypted link establishment.
Explain
Explain why the resulting association model can or cannot resist passive and active attacks.
Technical boundaries. The state path follows simplified BLE association and key-generation rules. It does not execute cryptography, model radio interception probability, bonding databases, privacy-address rotation, implementation bugs, repeated attempts, key distribution policy, or certification tests.
Observe — Choose Association
The selected method depends on the two devices. No display or keyboard usually means Just Works.
Explain — Prove The Peer
Passkey, Numeric Comparison, and suitable OOB data add a user-verifiable step that blocks simple MITM attacks.
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.
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
Feature flags choose what can be secured.
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
- Start with the default smart lock scenario and press Step once per phase.
- Change the peripheral IO to NoInputNoOutput and notice how the method downgrades.
- Switch from LE Secure Connections to Legacy to see why the page warns about weaker legacy security.
- 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.