18  Bluetooth Security: Labs and Defense-in-Depth

In 60 Seconds

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

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.

18.1 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

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.

18.2 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

18.3 Interactive Lab: BLE Security Demonstration

18.3.1 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

18.3.2 What You’ll Build

An ESP32 BLE security demonstration that shows:

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

18.3.3 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

18.3.4 Circuit Diagram

Figure 18.1: ESP32 BLE Security Lab Circuit Wiring

18.3.5 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.

18.3.6 Lab Challenges

Try these experiments to understand BLE security:

18.3.6.1 Challenge 1: Compare Security Modes

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

Steps:

1. Upload code in secure mode (default)
2. Open nRF Connect app on phone
3. Scan for “SecureIoTDevice”
4. Attempt to connect - Prompted for PIN: 123456
5. After entering PIN, observe encrypted connection
6. Press button to restart in insecure mode
7. Connect again - No PIN required
8. 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.

18.3.6.2 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:

1. Start BLE packet capture with nRF Sniffer
2. Connect phone to ESP32 in insecure mode
3. Observe data packets in Wireshark
4. Find characteristic write/notify packets
5. View temperature data in plaintext: “Temp: 24.5 C”
6. Repeat in secure mode
7. 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.

18.3.6.3 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×.

18.3.6.4 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)

18.3.7 Lab Takeaways

After completing this lab, you should understand:

1. 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)
2. 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
3. Defense in depth
   • BLE security (pairing + encryption)
   • Application security (authentication/authorization)
   • Physical security (tamper-evident casing)
   • Firmware security (secure boot)
4. 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
5. 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

Check Your Understanding: Lab Concepts

Interactive: PIN Brute-Force Time Calculator

Experiment with lockout parameters to see how rate limiting defends against brute-force attacks on BLE pairing PINs.

viewof pinLength = Inputs.range([4, 8], {
  value: 6,
  step: 1,
  label: "PIN Length (digits)"
})

viewof attemptsBeforeLock = Inputs.range([1, 10], {
  value: 3,
  step: 1,
  label: "Attempts Before Lockout"
})

viewof lockDuration = Inputs.range([10, 600], {
  value: 60,
  step: 10,
  label: "Lockout Duration (seconds)"
})

{
  const total = Math.pow(10, pinLength);
  const avgGuesses = total / 2;
  const secPerAttempt = 1;

  // No lockout
  const noLockTime = avgGuesses * secPerAttempt;
  const noLockDays = noLockTime / 86400;

  // With lockout
  const cycleAttempts = attemptsBeforeLock;
  const cycleTime = (cycleAttempts * secPerAttempt) + lockDuration;
  const cycles = avgGuesses / cycleAttempts;
  const lockTime = cycles * cycleTime;
  const lockDays = lockTime / 86400;

  const slowdown = (lockTime / noLockTime).toFixed(1);

  const color1 = "#2C3E50";
  const colorGood = "#16A085";
  const colorBad = "#E74C3C";

  const formatTime = (seconds) => {
    if (seconds < 3600) return (seconds / 60).toFixed(0) + " min";
    if (seconds < 86400) return (seconds / 3600).toFixed(1) + " hours";
    if (seconds < 86400 * 365) return (seconds / 86400).toFixed(0) + " days";
    return (seconds / (86400 * 365)).toFixed(1) + " years";
  };

  return html`<div style="background: #f8f9fa; border-radius: 8px; padding: 1.2rem; font-family: Arial, sans-serif;">
    <div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(200px, 1fr)); gap: 1rem; margin-bottom: 1rem;">
      <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${color1};">
        <div style="font-size: 0.85rem; color: #666;">PIN Combinations</div>
        <div style="font-size: 1.5rem; font-weight: bold; color: ${color1};">${total.toLocaleString()}</div>
      </div>
      <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${colorBad};">
        <div style="font-size: 0.85rem; color: #666;">No Rate Limiting</div>
        <div style="font-size: 1.5rem; font-weight: bold; color: ${colorBad};">${formatTime(noLockTime)}</div>
      </div>
      <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${colorGood};">
        <div style="font-size: 0.85rem; color: #666;">With Lockout</div>
        <div style="font-size: 1.5rem; font-weight: bold; color: ${colorGood};">${formatTime(lockTime)}</div>
      </div>
      <div style="background: white; padding: 1rem; border-radius: 6px; border-left: 4px solid ${colorGood};">
        <div style="font-size: 0.85rem; color: #666;">Slowdown Factor</div>
        <div style="font-size: 1.5rem; font-weight: bold; color: ${colorGood};">${slowdown}x</div>
      </div>
    </div>
    <div style="font-size: 0.8rem; color: #666;">Average case: attacker tries half of all ${total.toLocaleString()} combinations. Lockout after ${attemptsBeforeLock} attempts with ${lockDuration}s penalty increases attack time by ${slowdown}x.</div>
  </div>`;
}

18.4 Defense-in-Depth Security Layers

Secure BLE deployments require protection at multiple layers:

Figure 18.2: Defense-in-depth layers for BLE security showing how each layer blocks different attack vectors.

18.5 BLE Attack Timeline Visualization

Understanding when attacks can occur helps prioritize defenses:

Figure 18.3: Attack timeline showing vulnerability windows throughout the BLE device lifecycle.

18.6 Visual Reference Gallery

Visual: Bluetooth Pairing Process

Bluetooth pairing key exchange

The pairing process establishes shared encryption keys between devices using one of four authentication methods.

Visual: Bluetooth Pairing Modes

Bluetooth pairing mode comparison

Pairing mode selection should match the security requirements of your application and the device’s I/O capabilities.

Visual: BLE State Machine

BLE connection state machine

Understanding BLE states helps identify attack surfaces and implement appropriate security controls at each stage.

Visual: Bluetooth Power Classes

Bluetooth power class and range

Power class affects not only range but also security perimeter - higher power means larger attack surface area.

Visual: Bluetooth Protocol Stack Security

BLE stack security layers

Security must be implemented at multiple stack layers - link encryption alone is insufficient for sensitive applications.

18.7 Knowledge Check

Auto-Gradable Quick Check

18.7.1 Knowledge Check: Defense-in-Depth for BLE

18.7.2 Knowledge Check: BLE Attack Surface

Common Mistake: Ignoring Bonded Key Storage Security

The Scenario: A smart lock manufacturer implements authenticated BLE pairing with Numeric Comparison but stores bonded LTK keys in unencrypted flash memory. After deployment, a security researcher extracts the keys through exposed debug access and demonstrates that cloned clients can reconnect as trusted devices.

What Went Wrong: Secure pairing means nothing if the resulting keys are not securely stored. Many developers focus on the pairing ceremony (Numeric Comparison, OOB) but neglect key storage, assuming the device’s physical security is sufficient.

Vulnerable implementation pattern:

• Bonding keys are saved to ordinary flash without flash encryption.
• JTAG or SWD debug access remains enabled in production.
• The enclosure allows simple access to programming pads.
• There is no process to revoke bonds after a suspected key leak.

Attack Vector:

1. Attacker removes smart lock cover (2 screws)
2. Connects USB debugger (ST-Link, J-Link) to exposed JTAG/SWD pins
3. Dumps flash memory contents (5 minutes)
4. Extracts bonded keys from known NVS partition offsets
5. Creates spoofed central device using extracted keys
6. Locks now accept attacker’s device as trusted

Secure implementation pattern:

• Enable flash encryption before production release.
• Disable debug interfaces or lock them behind an authenticated service process.
• Store long-lived secrets in protected flash or a secure element when the risk justifies the cost.
• Add a bond-revocation path so extracted or lost credentials can be invalidated.

Defense Checklist:

• Enable flash encryption (ESP32/nRF52: burns eFuses, permanent)
• Disable debug interfaces (JTAG/SWD) in production firmware
• Use tamper-evident enclosures (security screws, ultrasonic welds)
• Implement key rotation (refresh LTK every N days)
• Add intrusion detection (accelerometer detects case opening)

Deployment cost lesson: Retrofitting hardware security after release is usually more expensive than designing for protected storage and debug-port lockdown before manufacturing.

Concept Relationships

• Defense-in-depth and security layers: Link encryption protects traffic in transit, but production devices also need application authorization, secure boot, and protected key storage.
• Attack timeline and lifecycle security: Vulnerabilities can appear during manufacturing, pairing, normal operation, firmware update, resale, and decommissioning.
• Secure boot and firmware integrity: Signed boot prevents malicious firmware from disabling encryption or leaking bonded keys.
• LE Secure Connections and key agreement: ECDH-based pairing improves key establishment and prevents passive recovery of past session keys.
• Key storage protection and bonding security: Flash encryption, secure elements, and debug-port lockdown reduce the risk of LTK extraction.

18.8 See Also

• Bluetooth Security: Encryption and Key Management - Key hierarchy and AES-CCM details
• Bluetooth Security: Pairing Methods - OOB and Numeric Comparison selection
• BLE Comprehensive Review - Integrated security concepts
• IoT Security Threats and Fundamentals - Broader security context
• Hardware Security for IoT - Secure elements and eFuse protection

Interactive Quiz: Match Defense Mechanisms

Interactive Quiz: Sequence the Security Hardening

Label the Diagram

Code Challenge

18.9 Summary

This chapter provided hands-on experience with BLE security:

• Interactive Lab: ESP32-based demonstration comparing secure and insecure BLE modes
• Security Challenges: PIN brute-force protection, packet interception analysis, secure boot implementation
• Defense-in-Depth: Multi-layer security architecture from physical to data protection
• Attack Timeline: Vulnerability windows across device lifecycle (manufacturing, deployment, operation, decommissioning)
• Visual Gallery: Reference diagrams for pairing, encryption, and protocol stack security

Common Pitfalls

1. Testing Security Only at the BLE Protocol Layer

BLE security testing that focuses only on pairing and encryption misses vulnerabilities at other layers: unvalidated GATT write values causing buffer overflows, unauthenticated command execution (e.g., factory reset via GATT Write without security), or insecure bootloader allowing unsigned firmware. Test the complete attack surface including: physical access, JTAG/debug interfaces, UART console, GATT command handling, and OTA update integrity.

2. Relying on Device Address as Authentication

Using the BLE device MAC address as an authentication factor is insecure — MAC addresses are transmitted in cleartext in advertising packets and can be spoofed in software. An attacker can clone a trusted device’s MAC address to impersonate it. Authentication must use cryptographic methods: LESC pairing, application-layer token exchange, or certificate-based authentication, never MAC address matching.

3. Not Revoking Bonding Keys After Security Incident

When a bonded device is lost, stolen, or suspected compromised, the LTK stored in the remaining device’s NVS must be immediately deleted to prevent unauthorized reconnection. IoT devices without a mechanism to remotely revoke bonding keys (via cloud command + BLE or local physical trigger) remain permanently open to the lost device reconnecting with the stolen key. Always implement a key revocation path in production firmware.

4. Ignoring Firmware Update Authentication

An OTA DFU implementation that accepts unsigned firmware images allows an attacker within BLE range to flash arbitrary malicious firmware. All production BLE OTA implementations must verify firmware image signatures (ECDSA or RSA) before applying updates. The public key for signature verification should be stored in a protected flash region that cannot be overwritten by OTA updates themselves.

18.10 What’s Next

Prioritize these follow-up chapters based on the security question you need to answer next:

• Bluetooth Comprehensive Review: use integrated case studies and assessment questions to validate Bluetooth security understanding before deployment.
• Bluetooth Security: Pairing Methods: compare Just Works, Passkey Entry, Numeric Comparison, and OOB when choosing the right pairing method for a threat model.
• Bluetooth Security: Encryption and Key Management: review AES-CCM operation, LTK/STK/IRK hierarchy, and secure key distribution before implementing firmware.
• IoT Security Threats and Fundamentals: place BLE attack vectors in the broader IoT threat landscape.
• Hardware Security for IoT: deepen the secure boot, flash encryption, debug-port lockdown, and secure-element topics introduced in this lab.