BLE Attack Labs: Security Review

bluetooth-ble

security

defense

This lab belongs to BLE Encryption: Secure Pairing

Start With the Decision

A BLE lock can pair and still fail under attack. Test its PIN, keys, and recovery path.

Route Overview

This is part 1 of 2. Continue with BLE Attack Labs: PIN Brute-Force Timing.

Part Objectives

Test lab security review pattern against named attack, failure, and recovery cases.
Validate putting numbers to it with a concrete scenario and pass criteria.

In 60 Seconds

Begin with one protected action. A phone asks a lock to open. 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.

Write the allowed case first. Name the user. Name the device. Name the action. Set the time and place limits. Then write the cases that must fail. Include a lost phone and an old key.

A lab should make each check visible. Try an unknown phone. Try a changed command. Try the same command twice. Try many wrong guesses. Break the link during the action. Save what the device did.

Add guards in layers. Protect the local exchange. Check permission inside the product. Limit repeated guesses. Accept new device software only from a trusted source. Protect stored secrets. Provide a safe way to remove access.

Repeat the same tests after each change. A fix passes only the named case. It does not prove that every path is safe. Record the device version, setup, action, and result. Keep failed cases in the final report.

This quick view uses one lock. Real products cross phones, online services, and support work. Practitioner tests make those paths repeatable. 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. Production deployments need application-layer authorization, secure firmware updates, rate limiting against brute-force attacks, and physical security considerations covering the entire device lifecycle from manufacturing to decommissioning.

Key Concepts

BLE Security Lab Tools: nRF Sniffer (passive capture), btlejack (active BLE MITM/sniff), Wireshark BLE dissector, nRF Connect (GATT inspection), crackle (legacy BLE key recovery)
MITM Attack on Just Works: Passive attacker captures BLE 4.x Just Works pairing exchange; crackle tool recovers TK (always 0 for Just Works) and derives LTK from STK offline
BLE Fuzzing: Sending malformed ATT/GATT PDUs (invalid handle ranges, out-of-bounds characteristic values) to test server input validation; public research tools and vendor test harnesses are useful references
BLE Stack Vulnerabilities: Published BLE implementation bugs have caused crashes, lockups, and code execution in vendor SDKs, so firmware patching and input validation remain part of the security plan
Passive Reconnaissance: BLE advertisement sniffing with ubertooth-btle or nRF Sniffer to enumerate nearby devices, their services (via extended advertising or connection), and RSSI for location estimation
Defense-in-Depth for BLE: Layered security approach: LE Secure Connections pairing + encrypted transport + application-layer authentication + firmware signing + OTA update monitoring
BLE Penetration Testing Methodology: Enumerate (advertising sniff) → Identify (service discovery) → Probe (characteristic fuzzing) → Exploit (known CVEs) → Persist (firmware modification)
Security Hardening Checklist: Disable Just Works for sensitive devices; enforce minimum security mode; validate all characteristic writes server-side; sign firmware images; use RPA for privacy
Bluejacking: Low-severity nuisance attack that sends unsolicited messages or data to a discoverable device; mitigate by disabling discoverability outside of an intentional pairing window rather than treating it as a serious threat on its own

Quick Check: Bluetooth Security Boundary

Minimum Viable Understanding

BLE security must be implemented in layers (defense-in-depth): link-layer encryption via authenticated pairing is necessary but not sufficient. 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.

Learning Objectives

By the end of this chapter, 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
Configure Rate Limiting Defenses: Apply brute-force lockout logic and calculate the time-to-crack improvement achieved by rate limiting

Chapter Roadmap

In 60 Seconds
Key Concepts
Quick Check: Bluetooth Security Boundary
Minimum Viable Understanding
For Beginners: Labs and Defense-in-Depth
Lab Security Review Pattern
Prerequisites
Interactive Lab: BLE Security Demonstration
Checkpoint: Lab Boundary
Checkpoint: Capture Evidence
Putting Numbers to It
Checkpoint: Rate-Limit Math
Knowledge Check: Lab Concepts

Use this lab as a security review in four passes:

First build the secure/insecure ESP32 comparison so pairing, encryption, and the visible device state are testable.
Then capture the radio evidence: which payloads become plaintext, which packets stay opaque, and which metadata still leaks.
Next add online-abuse controls such as the 3-failure, 60-second lockout and check the math instead of trusting the label.
Finally widen the defense boundary to firmware signing, bonded-key storage, ATT permissions, application authorization, and recovery.

The checkpoints below mark each pass so the lab record shows what changed before another layer is added.

For Beginners: Labs and Defense-in-Depth

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.

Lab Security Review Pattern

Use each lab as a security review checklist, not just a code exercise:

Compare secure and insecure BLE modes so the pairing, encryption, and user-verification differences are visible.
Capture only your own lab device traffic, then confirm what an eavesdropper can and cannot read.
Add application-layer authorization for sensitive commands, even after a device is paired.
Rate-limit repeated authentication failures so PINs and short secrets cannot be guessed quickly.
Protect firmware, stored keys, debug ports, and decommissioning flows because wireless security fails if the device can be reflashed or cloned.

Prerequisites

Before diving into this chapter, you should be familiar with:

Bluetooth Security: Pairing Methods: Understanding BLE pairing and authentication
Bluetooth Security: Encryption and Key Management: Key hierarchy and security framework
Bluetooth Implementations and Labs: Basic ESP32 BLE programming experience

Interactive Lab: BLE Security Demonstration

Lab Objective

Explore how different BLE security modes affect data transmission and device pairing. This hands-on lab demonstrates:

Secure pairing with PIN verification
Encrypted vs unencrypted data transmission
MAC address randomization (privacy feature)
Security flags in BLE advertising

What You’ll Build

An ESP32 BLE security demonstration that shows:

Secure mode: Requires pairing with PIN, encrypts all data
Insecure mode: Accepts any connection, transmits data in plaintext
Security indicators: Visual feedback showing security state

Hardware Requirements

For Wokwi Simulator:

ESP32 DevKit v1
LED (Red = Insecure, Green = Secure)
Push button (toggle security modes)
No physical hardware needed!

For Real Hardware:

ESP32 DevKit v1
2x LEDs (Red + Green)
2x 220 Ohm resistors
Push button
Breadboard + jumper wires

Circuit Diagram

Before applying power, inspect Figure to trace every current path and input reference. The diagram makes the secure/insecure indicators visually distinct while keeping both LEDs and the mode button on one common ESP32 ground.

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.

Read Figure from GPIO 4 through its 220-ohm resistor and green LED to ground, then repeat the check from GPIO 2 through the red branch. Finally follow GPIO 5 to the push button and verify its return and configured pull state. That order connects the physical build to the software modes below: a reversed LED, missing resistor, or floating input can produce misleading “security” observations even when the BLE code is correct.

Lab Code: BLE Security Demo

Open the simulator directly: Wokwi ESP32 starter project.

Use the starter project as a safe place to build the demo. Keep the implementation focused on these checkpoints:

Security callbacks: return a demo passkey, display it in the serial console, confirm pairing requests, and log whether authentication succeeds or fails.
Secure mode configuration: require LE Secure Connections with MITM protection and bonding, use a 128-bit key size, and set the device I/O capability to match the passkey workflow.
Insecure mode configuration: deliberately allow a no-MITM or unauthenticated path only for comparison. Label this mode clearly so it is never mistaken for production code.
Notification loop: publish the same sample temperature value in both modes, then compare what a sniffer can read from encrypted and plaintext connections.
State indicators: use the LEDs and serial log to show whether the device is waiting for pairing, paired securely, or running in the insecure test mode.

Checkpoint: Lab Boundary

You now know:

The lab device has two intentionally different modes: secure mode asks for PIN 123456, while insecure mode accepts a connection without that pairing step.
The ESP32 setup is not just a demo circuit; the red/green LEDs, serial log, and phone connection flow are evidence that the mode changed.
The same sample temperature notification appears in both paths, which gives the packet-capture challenge a fair before/after comparison.

With the lab boundary explicit, the next question is what an observer can see from outside the device.

Lab Challenges

Try these experiments to understand BLE security:

Challenge 1: Compare Security Modes

Task: Connect to the device in both secure and insecure modes using nRF Connect app.

Run it: The connection you are about to compare is a walk through the BLE link-layer states, so trace it first in the state-machine workbench below. Step the peripheral from Standby into Advertising, then bring a central through Scanning and Initiating until the Connection state forms — the same path nRF Connect drives when it scans for and connects to the device. Note that both secure and insecure modes traverse these link states; the difference is the pairing and encryption step layered on top once the connection exists, which is what makes the secure connection slower.

Steps:

Upload code in secure mode (default)
Open nRF Connect app on phone
Scan for “SecureIoTDevice”
Attempt to connect - Prompted for PIN: 123456
After entering PIN, observe encrypted connection
Press button to restart in insecure mode
Connect again - No PIN required
Compare connection process

Question: Which mode connected faster? Why?

Answer

Insecure mode is faster because it skips authentication. However, this speed comes at a security cost:

Secure mode (slow but safe):

Connection includes a pairing/authentication step
Requires a user interaction step (PIN in this demo)
Uses link-layer encryption after pairing (AES-CCM 128-bit)
MITM protection depends on the pairing method

Insecure mode (fast but dangerous):

Connection is typically faster (no pairing step)
No verification needed
Data sent in plaintext
Vulnerable to eavesdropping

Real-world trade-off: For public sensor data, plaintext might be acceptable. For control actions or sensitive data, prefer authenticated pairing and add application-layer authorization.

Challenge 2: Intercept Plaintext Data

Task: Use Wireshark or nRF Sniffer to capture BLE packets and view unencrypted data.

Requirements:

A BLE sniffer (e.g., nRF52840 dongle running nRF Sniffer)
Wireshark (with the appropriate BLE capture integration)
nRF Sniffer firmware/tools

Steps:

Start BLE packet capture with nRF Sniffer
Connect phone to ESP32 in insecure mode
Observe data packets in Wireshark
Find characteristic write/notify packets
View temperature data in plaintext: “Temp: 24.5 C”
Repeat in secure mode
Observe encrypted packets (unreadable hex data)

Question: What information can an attacker learn from plaintext BLE packets?

Answer

Without encryption, an eavesdropper can see the payloads and metadata:

Device address/identifiers (tracking risk if privacy features aren’t used)
Sensor data in plaintext (e.g., temperature strings)
Service/Characteristic UUIDs (can reveal device type/capabilities)
Connection patterns (timing, frequency, active periods)
Commands sent to the device (replay may be possible)

With encryption (secure mode), an eavesdropper typically only sees:

Packet timing/length and protocol metadata
Addresses that may be randomized (privacy feature)
Nothing about actual data content

Privacy lesson: Metadata leakage is real! Even encrypted, BLE reveals when devices communicate.

Checkpoint: Capture Evidence

You now know:

Insecure mode can expose the sample payload, such as Temp: 24.5 C, plus UUIDs, timing, connection patterns, and device identifiers.
Secure mode protects the payload with link encryption, but packet timing, packet length, and address behavior can still support tracking analysis.
The lab needs both traces in the record: one that proves plaintext risk and one that proves the mitigation changed what Wireshark can decode.

After capture, the attack becomes active: can repeated pairing attempts turn a short PIN into a practical online guessing path?

Challenge 3: Implement PIN Brute-Force Protection

Task: Modify the code to lock out attackers after 3 failed pairing attempts.

Requirements:

Track failed pairing attempts
Lock device for 60 seconds after 3 failures
Log all pairing attempts with timestamps

Solution Outline

Implement the lockout as a small state machine:

Add failedAttempts and lockoutUntil as persistent state.
At the start of the authentication callback, reject new pairing attempts while millis() < lockoutUntil.
On successful authentication, reset failedAttempts, clear any warning indicator, and log the accepted peer.
On failed authentication, increment failedAttempts and log the timestamp, peer address if available, and failure count.
When the failure count reaches 3, set lockoutUntil = millis() + 60000, turn on the warning indicator, and reset the counter for the next lockout window.

Security improvement: This does not make a weak PIN strong, but it changes brute-force guessing from a rapid online attack into a slow, noisy process that operators can detect.

Putting Numbers to It

With a 6-digit PIN, an attacker has 1 million possible combinations ( $10^6 = 1,000,000$ ). If allowed unlimited attempts:

$\text{Average attempts to guess} = \frac{1,000,000}{2} = 500,000$

Worked example: With a 3-attempt lockout and 60-second penalty, an attacker trying one PIN pattern needs:

3 attempts × 1 second per attempt = 3 seconds
Wait 60 seconds (lockout)
Total: 63 seconds per 3 attempts
Time to exhaust all combinations: $\frac{1,000,000}{3} \times 63 \text{ seconds} = 21,000,000 \text{ seconds} \approx 243 \text{ days}$

Compare to unlimited attempts: $1,000,000 \text{ seconds} = 11.6 \text{ days}$ . The lockout increases attack time by 21×.

Checkpoint: Rate-Limit Math

You now know:

A 6-digit PIN has 1,000,000 combinations, so the average guess lands after about 500,000 attempts.
With 3 tries followed by a 60-second penalty, each cycle costs 63 seconds and full exhaustion is about 21,000,000 seconds, or 243 days.
That is a 21x slowdown compared with 1,000,000 seconds, but it is still only an online friction control; sensitive products should avoid weak pairing choices in the first place.

Once the online attack is slowed, protect the firmware and stored secrets that could bypass pairing entirely.

Challenge 4: Advanced - Implement Secure Boot

Task: Ensure the ESP32 firmware cannot be tampered with by enabling secure boot.

Why this matters: Even with secure BLE pairing, if an attacker can reflash the ESP32 with malicious firmware (e.g., one that leaks the PIN or disables encryption), all security is lost.

Implementation Guide

Secure Boot prevents:

Flashing unauthorized firmware
Booting malicious code
Firmware tampering

Implementation steps (ESP32-IDF):

Generate a secure-boot signing key and store it outside the source repository.
Enable secure boot in idf.py menuconfig under the security features menu.
Build and flash a fully tested image only after confirming the device can still be recovered during development.
On first production boot, the relevant eFuses are burned and future firmware must be signed with the trusted key.

Warning: Secure boot is permanent on production devices. If you lose the signing key, the device may become effectively unupdatable.

Production deployment checklist:

Store signing key in hardware security module (HSM)
Implement firmware update mechanism with signed images
Test thoroughly before burning eFuses
Keep multiple backup copies of signing key (encrypted, offline)

Lab Takeaways

After completing this lab, you should understand:

Pairing modes matter more than encryption strength
- Even strong link encryption won’t help if pairing is unauthenticated (“Just Works”)
- Prefer authenticated pairing (Numeric Comparison or OOB; Passkey Entry when appropriate)
Security vs. Convenience trade-off
- Secure mode: Slower connection, better security
- Insecure mode: Faster connection, vulnerable to attacks
- Choose based on data sensitivity and threat model
Defense in depth
- BLE security (pairing + encryption)
- Application security (authentication/authorization)
- Physical security (tamper-evident casing)
- Firmware security (secure boot)
Real-world deployment considerations
- For safety- or high-value devices: use authenticated pairing and plan for revocation
- For public sensors (weather, parking): Insecure mode may be acceptable
- For payment systems: Add NFC/QR out-of-band pairing
Attack surface extends beyond wireless
- Attacker with physical access can reflash firmware
- Use secure boot + tamper detection for critical devices
- Implement rate limiting to prevent brute-force

Knowledge Check: Lab Concepts

Continue to the Next Part

Carry this evidence into BLE Attack Labs: PIN Brute-Force Timing, which begins with Interactive: PIN Brute-Force Time Calculator.