Bluetooth & BLE · Study deck

BLE Attack Labs: Security Review

A Bluetooth Low Energy (BLE) lock can pair, or set up link keys, and still fail under attack.

Radio Remi is your guide for this deck.

securitydefense

After studying this chapter

Learning objectives

You will be able to:

Implement BLE Security in Code: Build and test secure vs insecure BLE configurations on ESP32, comparing encrypted vs plaintext data transmission
Design Defense-in-Depth Architectures: Construct multi-layer security schemes for BLE IoT deployments covering link, application, and firmware layers
Analyze Attack Vectors: Diagnose vulnerability windows throughout the device lifecycle, from manufacturing supply chain to decommissioning
Evaluate Pairing Method Trade-offs: Assess the security guarantees of Just Works, Passkey Entry, Numeric Comparison, and OOB against realistic threat models

Major section

In 60 Seconds

The lock must know which phone is asking.

It must also know whether that user may open this door.
A hidden radio exchange does not answer both questions.
A lab should make each check visible.

Major section

In 60 Seconds (continued)

Real products cross phones, online services, and support work.

Under the Hood examines data permissions, key life, write checks, and the gaps that a successful pairing can hide.
BLE security requires defense-in-depth: link-layer encryption via pairing is necessary but not sufficient.
BLE security must be implemented in layers (defense-in-depth): link-layer encryption via authenticated pairing is necessary but not sufficient.

Major section

Minimum Viable Understanding

Production deployments need application-layer authorization for sensitive commands, secure firmware updates (secure boot), rate limiting against brute-force attacks, and physical security considerations.

Attacks can occur at every lifecycle stage -- from manufacturing supply chain to device decommissioning -- so security planning must cover the entire device lifetime.
These labs give you hands-on experience with Bluetooth security -- scanning for nearby devices, analyzing pairing processes, and understanding how to defend against common attacks.
Think of it as learning home security by actually testing locks and alarm systems, so you understand both how they work and how they can be strengthened.

Major section

Interactive Lab: BLE Security Demonstration

No physical hardware is needed to rehearse the LED and button logic.

The lockout increases attack time by 21×.
BLE pairing, encryption, and packet capture require your own ESP32 and radio tools.

ESP32 BLE security lab circuit showing GPIO 4 wired through a 220 ohm resistor to the green secure-mode LED, GPIO 2 wired through a 220 ohm resistor to the red insecure-mode LED, GPIO 5 wired to the mode-toggle push button, and all returns tied to ESP32 ground.

Deck summary

Key takeaways

The lock must know which phone is asking.

Real products cross phones, online services, and support work.
Production deployments need application-layer authorization for sensitive commands, secure firmware updates (secure boot), rate limiting against brute-force attacks, and physical security considerations.
No physical hardware is needed to rehearse the LED and button logic.

Retrieval practice

Recall check 1 of 4

Radio Remi says: answer from memory, then check your reasoning.

Q1A reviewer is checking the Bluetooth security decision for this topic. Which evidence keeps the claim bounded?

AA statement that Bluetooth is common in consumer devices, without checking this deployment

BA successful connection screenshot with no power, security, or failure-behavior evidence

CPairing method, I/O assumptions, key storage, encryption level, authorization boundary, recovery plan.

DA decision to defer retest triggers until after deployment problems appear

Show answer

Answer: C Bluetooth security review should separate pairing, encryption, key management, authorization, and recovery evidence.

Retrieval practice

Recall check 2 of 4

Radio Remi says: answer from memory, then check your reasoning.

Q2A BLE device is safe during pairing but can be reflashed through an open debug port. What does this show?

AReview physical debug access and the firmware update lifecycle as well.

BAssume successful pairing also locks the open firmware debug port.

CTreat reflashing risk as ending automatically after manufacturing.

DIncrease radio signal strength instead of reviewing debug access.

Show answer

Answer: A Pairing cannot protect a device whose firmware can be replaced.

Retrieval practice

Recall check 3 of 4

Radio Remi says: answer from memory, then check your reasoning.

Q3A BLE device pairs securely but leaves an open debug port and old bond keys after resale. What does the review miss?

AOnly the choice of advertising interval

BOnly whether the phone app shows the device name

COnly whether the link uses a strong cipher

DFactory access and retirement paths as well as pairing

Show answer

Answer: D Attack windows include physical access and retained trust after ownership changes.

Q4A guard allows three failed guesses, each taking one second, then locks for sixty seconds. How many times longer is this cycle than the guesses alone?

ATwenty-one times longer

BTwenty times longer

CSixty times longer

DSixty-three times longer

Show answer

Answer: A Add the lockout to the guess time, then divide by the guess time.

Retrieval practice

Recall check 4 of 4

Radio Remi says: answer from memory, then check your reasoning.

Q5An IoT temperature sensor uses BLE 'Just Works' pairing and transmits readings every 10 seconds. Which specific attack does this configuration fail to prevent?

ARF jamming, assumed to be caused specifically by Just Works pairing.

BAn active pairing man-in-the-middle when Just Works lacks authentication.

CBattery drain from connection retries, unrelated to pairing authentication.

DJTAG firmware tampering, which depends on physical debug access.

Show answer

Answer: B Just Works gives no MITM protection during pairing, so an active attacker can control the links it establishes and read or relay data allowed on them.

Print reference

Answers

Answer key.

C · Bluetooth security review should separate pairing, encryption, key management, authorization, and recovery evidence.
A · Pairing cannot protect a device whose firmware can be replaced.
D · Attack windows include physical access and retained trust after ownership changes.
A · Add the lockout to the guess time, then divide by the guess time.
B · Just Works gives no MITM protection during pairing, so an active attacker can control the links it establishes and read or relay data allowed on them.