15 BLE Attack Labs: PIN Brute-Force Timing
15.1 Start With the Decision
A four-digit PIN can look safe until a script tries every value. Lockout time and retry limits decide how long the attack takes.
15.2 Route Overview
This is part 2 of 2. Review BLE Attack Labs: Security Review for the preceding evidence.
15.3 Learning Objectives
- Calculate interactive: pin brute-force time calculator from stated measurements and limits.
- Test 4. ignoring firmware update authentication against named attack, failure, and recovery cases.
15.4 Chapter Roadmap
- Interactive: PIN Brute-Force Time Calculator
- Defense-in-Depth Security Layers
- BLE Attack Timeline Visualization
- Visual Reference Gallery
- Visual: Bluetooth Pairing Process
- Visual: BLE State Machine
- Visual: Bluetooth Power Classes
- Visual: Bluetooth Protocol Stack Security
- Knowledge Check
- Auto-Gradable Quick Check
- Common Mistake: Ignoring Bonded Key Storage Security
- Checkpoint: Defense Stack
- Concept Relationships
- See Also
- Practice Activities
- Interactive Quiz: Match Defense Mechanisms
- Interactive Quiz: Sequence the Security Hardening
- Label the Diagram
- Code Challenge
- Start With the Story
- Deep Dive: ATT Permissions and Write Validation
- Summary
- Common Pitfalls
- 1. Testing Security Only at the BLE Protocol Layer
- 2. Relying on Device Address as Authentication
- 3. Not Revoking Bonding Keys After Security Incident
- 4. Ignoring Firmware Update Authentication
- What’s Next
- Key Takeaway
15.5 Defense-in-Depth Security Layers
Secure BLE deployments require protection at multiple layers. Inspect Figure 15.1 to ask what remains exposed when any single control fails; the aim is to avoid treating pairing or link encryption as the entire security architecture.
Read Figure 15.1 from the outside inward. Physical controls constrain access to the device, the radio perimeter limits exposure, link encryption protects over-the-air frames, application authentication decides who may invoke a function, and data protection limits damage to the underlying secret or record. The layers answer different threats, so the lab results should record which control stopped which attack rather than claiming one successful pairing test proves end-to-end security.
15.6 BLE Attack Timeline Visualization
Understanding when attacks can occur helps prioritize defenses. Follow Figure 15.2 across the whole device life so commissioning controls do not obscure supply-chain, operational, and retirement risks.
Read Figure 15.2 from manufacturing, where firmware and injected credentials establish the initial trust base, into deployment and its pairing window. Continue through operation, where eavesdropping, relay, authorization, and update risks persist, then finish at decommissioning, where retained bonds and data can outlive ownership. This sequence connects the hands-on lab to lifecycle policy: secure mode must include provenance, commissioning, maintenance, reset, and verified key destruction.
15.7 Visual Reference Gallery
Inspect Figure 15.3 to locate the decision that selects an association method before key generation begins. This stops the visible “connected” state from being confused with authenticated, encrypted application access.
Read Figure 15.3 from I/O capability exchange to authentication-method selection, then through key generation and encryption establishment. The chosen capabilities determine whether the exchange can resist MITM; encryption alone does not retroactively authenticate Just Works. This ordered path connects the gallery reference to the secure and insecure lab modes and tells you which event each callback should log.
Inspect Figure 15.4 to locate when a peer becomes observable, when it may initiate, and when security can protect a connection. Attack surface changes with state, so a single connected-state test is incomplete.
Read Figure 15.4 from standby into advertising or scanning, then follow initiating into connection and the return paths after timeout or disconnect. Advertising exposes identifiers and payloads before link encryption exists; initiating and connection introduce peer selection, authentication, authorization, and supervision concerns. The state view connects the lab’s callbacks to security timing: apply controls and logging at the transition where the relevant evidence actually appears.
Radio reach defines who may attempt an attack, so inspect Figure 15.5 before setting the lab’s physical test boundary. The class labels are planning references, not guarantees of installed range.
Read Figure 15.5 from Class 1 through Classes 2 and 3, comparing nominal transmit power and rough range before defining the likely observation perimeter. Higher power can enlarge that perimeter, but antenna gain, receiver sensitivity, walls, bodies, and interference also shape it. The security connection is practical: pairing-window, discovery, and rate-limit tests should include locations outside the intended user area rather than assuming the device stops at a catalogue distance.
Inspect Figure 15.6 to assign each security claim to the layer that enforces it. This prevents encrypted radio frames from being presented as proof that a connected user may perform every application action.
Read Figure 15.6 from link-layer encryption upward to GATT permissions and application authorization. Link protection provides confidentiality and integrity over the air; GATT restricts attribute operations; the application decides whether an authenticated identity may invoke the requested business function and how sensitive data is handled. The layered walk-through reconnects this gallery item to defense in depth: a complete test needs evidence at all three boundaries.
15.8 Knowledge Check
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:
- Attacker removes smart lock cover (2 screws)
- Connects USB debugger (ST-Link, J-Link) to exposed JTAG/SWD pins
- Dumps flash memory contents (5 minutes)
- Extracts bonded keys from known NVS partition offsets
- Creates spoofed central device using extracted keys
- 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.
Checkpoint: Defense Stack
You now know:
- BLE link encryption uses AES-CCM with 128-bit keys, but link encryption only protects traffic in transit.
- Defense-in-depth adds application-layer authorization, signed firmware, flash encryption, protected bonded-key storage, and a revocation path.
- Physical access matters: the chapter’s bonded-key scenario needs only two screws, a debugger, and about 5 minutes when production debug access is left open.
- The final lab record should prove both denial paths and allowed paths: unauthenticated writes fail, malformed authorized writes fail, and valid authorized commands still work.
The remaining sections consolidate those layers into a study map, practice checks, and common deployment mistakes.
- 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.
15.9 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
15.10 Practice Activities
15.11 Start With the Story
Picture a smart lock that opens after a nearby phone asks. The phone and lock may have made a protected link. That does not prove the person may open this door. It also does not prove the lock will reject a changed or repeated command.
A security lab turns these hidden questions into visible tests. Start with one action. State who should be allowed to request it. State what the device should reject. Then try the wrong person, wrong message, and wrong time. Save the evidence from each result.
Use several layers of defense. The wireless link can hide data from a nearby listener. The product must still check permission. The device must limit repeated guesses. New software must come from a trusted source. Lost phones and old keys need a removal path. Physical access also changes the risk.
Run the weak case first. Capture what an attacker can see or change. Apply one protection. Repeat the same test. A passing result should name the exact action and setup. It should not claim that the whole product is safe.
This first view uses a small door command. Real attacks can cross the phone, device, cloud service, and recovery process. The Practitioner layer builds repeatable lab records and fixes. Under the Hood examines data permissions, write checks, key storage, and the cases that a simple pairing test cannot cover.
A security lab should make invisible trust visible. If a setup is vulnerable to weak pairing, passive capture, relay assumptions, or bad recovery, the lab needs to produce evidence before the field deployment does.
Use this chapter as a small defense review. Run the attack or failure pattern, capture the trace, apply the mitigation, and leave a record that says exactly what changed and what still needs retesting.
15.12 Deep Dive: ATT Permissions and Write Validation
A useful BLE security lab starts by inventorying the ATT operations before testing pairing or packet capture. Write down every characteristic, the operations it permits, and the minimum security level expected for each operation. That map often exposes the real defect faster than radio analysis: a command characteristic left writable by any nearby phone.
| ATT operation | Security question | Failure if left open |
|---|---|---|
| Read | Who may pull the current value? | A nearby client can read state, identity, or sensor values. |
| Write / Write Command | Who may change the value? | A nearby client can change configuration or actuate hardware. |
| Notify | Who may subscribe through the CCCD? | A nearby client can receive a continuing telemetry stream. |
| Indicate | Who may receive acknowledged updates? | Reliability improves delivery, but does not add authorization. |
A GATT server assigns each attribute a security level for its operations. This permission setting, not the secrecy of the UUID, is what protects the device:
| Permission level | Who can perform the operation |
|---|---|
| Open (no security) | Any device in radio range, no pairing |
| Encryption required | Only a paired device on an encrypted link using the LTK |
| Authentication required | Only a device paired with MITM protection such as Numeric Comparison or Passkey Entry |
The classic vulnerability is a writable command characteristic left at Open. A smart lock whose unlock characteristic accepts a Write Command with no security lets anyone within range enumerate the UUID, send 0x01, and open the door. Changing from Write Command to Write Request only adds an ATT response; changing the UUID only delays discovery. The meaningful test result changes only when the write permission becomes authentication-required and the unauthenticated write fails before the latch callback runs.
Permissions are still only one layer. A bonded, authorized client can send malformed or malicious data through a legitimate Write, so the application must validate every written value. For a lock command, validate the opcode, door identifier, requested open time, nonce, and message authentication value before the latch moves. Reject unexpected lengths, unknown opcodes, replayed nonces, and unsafe durations such as 255 seconds, then log and rate-limit failures. In the lab, prove both sides: one unauthorized write fails at ATT permission checks, and one malformed authorized write fails in the application parser.
15.13 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
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.
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.
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.
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.
15.14 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.
15.15 Key Takeaway
Security labs should prove both allowed and denied paths. Test pairing, encryption, authorization, key reuse, and failed access attempts so defensive behavior is visible rather than assumed.
15.16 Continue Your Route
This final part closes the route from Interactive: PIN Brute-Force Time Calculator through Key Takeaway. Return to BLE Attack Labs: Security Review or continue from the bluetooth-ble module index.