Just Works

What Is Just Works Pairing?

pairing without MITM protection." data-category="Security">Just Works is the simplest BLE pairing association model. It requires zero user interaction -- no passkey entry, no numeric comparison, no external channel. The devices exchange keys and establish encryption automatically. While convenient, Just Works provides no protection against active man-in-the-middle (MITM) attacks.

When Just Works Is Selected

The SMP selects the association model based on the I/O capabilities that both devices advertise during Phase 1 of pairing. Just Works is chosen when at least one device has "NoInputNoOutput" capabilities -- a common scenario for headless sensors, beacons, and wearables that lack displays or keyboards.

Security Properties

Just Works provides encryption (AES-128-CCM) against passive eavesdropping, but no authentication. An attacker positioned between the two devices can impersonate both sides, intercepting and relaying traffic (a classic MITM attack). The resulting security level is Mode 1 Level 2 (unauthenticated encrypted).

With LESC, Just Works gains the benefit of ECDH key exchange, which makes passive eavesdropping infeasible even though the MITM vulnerability remains. With Legacy Pairing, Just Works sets the TK to zero, making passive eavesdropping trivial. Therefore, Just Works + LESC is significantly more secure than Just Works + Legacy.

Practical Usage

Despite its security limitations, Just Works is the most widely deployed association model in BLE. The majority of consumer IoT devices -- fitness bands, environmental sensors, smart home accessories, Bluetooth tags -- use Just Works because they lack the hardware for other models. The rationale is pragmatic: the threat of a sophisticated, real-time MITM attack against a room-temperature sensor is minimal compared to the usability cost of requiring passkey entry.

Hardening Just Works

Applications that must use Just Works but need higher security can layer additional protection:

• Application-layer encryption -- encrypt sensitive payloads with keys exchanged via a secure backend (e.g., cloud-provisioned AES keys).
• Certificate-based authentication -- after the BLE link is established, exchange and verify X.509 certificates or pre-shared tokens at the application layer.
• Proximity verification -- use RSSI thresholds or Channel Sounding to reject connections from devices that are not physically close.

These mitigations add complexity but can bring effective security close to authenticated pairing for specific deployment scenarios.