Bluetooth & BLE · Study deck
BLE Attack Labs: PIN Brute-Force Timing
A four-digit PIN can look safe until a script tries every value.
Radio Remi is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- 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.
- '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
Major section
Defense-in-Depth Security Layers
Secure BLE deployments require protection at multiple layers.
- 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.
Major section
BLE Attack Timeline Visualization
Understanding when attacks can occur helps prioritize defenses.
- This sequence connects the hands-on lab to lifecycle policy: secure mode must include provenance, commissioning, maintenance, reset, and verified key destruction.
Major section
Visual: Bluetooth Pairing Process
This stops the visible “connected” state from being confused with authenticated, encrypted application access.
- 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.
Major section
Visual: BLE State Machine
Attack surface changes with state, so a single connected-state test is incomplete.
- The state view connects the lab's callbacks to security timing: apply controls and logging at the transition where the relevant evidence actually appears.
Major section
Visual: Bluetooth Power Classes
The class labels are planning references, not guarantees of installed range.
- 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.
Major section
Visual: Bluetooth Protocol Stack Security
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.
Major section
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.
- Many developers focus on the pairing ceremony (Numeric Comparison, OOB) but neglect key storage, assuming the device's physical security is sufficient.
- JTAG or SWD debug access remains enabled in production.
Major section
Common Mistake: Ignoring Bonded Key Storage Security (continued)
Deployment cost lesson:: Retrofitting hardware security after release is usually more expensive than designing for protected storage and debug-port lockdown before manufacturing.
- Bonding keys are saved to ordinary flash without flash encryption.
- Attacker removes smart lock cover (2 screws).
- Locks now accept attacker's device as trusted.
Major section
Concept Relationships
Secure boot and firmware integrity: Signed boot prevents malicious firmware from disabling encryption or leaking bonded keys.
- 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.
- LE Secure Connections and key agreement: ECDH-based pairing improves key establishment and prevents passive recovery of past session keys.
Major section
Start With the Story
The phone and lock may have made a protected link.
- It also does not prove the lock will reject a changed or repeated command.
- A security lab turns these hidden questions into visible tests.
- The wireless link can hide data from a nearby listener.
- The product must still check permission.
Major section
Start With the Story (continued)
Under the Hood examines data permissions, write checks, key storage, and the cases that a simple pairing test cannot cover.
- 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.
Major section
Start With the Story (continued)
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.
Major section
Deep Dive: ATT Permissions and Write Validation
Changing from Write Command to Write Request only adds an ATT response; changing the UUID only delays discovery.
- A useful BLE security lab starts by inventorying the ATT operations before testing pairing or packet capture.
- The classic vulnerability is a writable command characteristic left at Open.
- Permissions are still only one layer.
Major section
Deep Dive: ATT Permissions and Write Validation (continued)
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.
- The meaningful test result changes only when the write permission becomes authentication-required and the unauthenticated write fails before the latch callback runs.
- A bonded, authorized client can send malformed or malicious data through a legitimate Write, so the application must validate every written value.
- In the lab, prove both sides: one unauthorized write fails at ATT permission checks, and one malformed authorized write fails in the application parser.
Deck summary
Key takeaways
Secure BLE deployments require protection at multiple layers.
- Understanding when attacks can occur helps prioritize defenses.
- This stops the visible “connected” state from being confused with authenticated, encrypted application access.
- Attack surface changes with state, so a single connected-state test is incomplete.
- The class labels are planning references, not guarantees of installed range.
Retrieval practice
Recall check 1 of 4
Radio Remi says: answer from memory, then check your reasoning.
Q1Which BLE pairing method provides the strongest protection against eavesdropping?
Show answer
Answer: D OOB uses a separate channel (e.g., NFC) to exchange pairing data, raising the bar for attackers because they must compromise both channels simultaneously.
Q2What is the main security improvement introduced by BLE 4.2 LE Secure Connections?
Show answer
Answer: B LE Secure Connections (BLE 4.2+) replaces legacy pairing with ECDH-based key agreement, providing protection against passive eavesdropping of pairing exchanges.
Retrieval practice
Recall check 2 of 4
Radio Remi says: answer from memory, then check your reasoning.
Q3What is the key difference between pairing and bonding in BLE?
Show answer
Answer: C Pairing creates the shared secrets for the current session; bonding persists them so trusted devices can reconnect securely without repeating the full pairing flow.
Retrieval practice
Recall check 3 of 4
Radio Remi says: answer from memory, then check your reasoning.
Q4Why is BLE link-layer encryption alone insufficient for securing an IoT smart lock?
Show answer
Answer: B Even with encrypted BLE links, an attacker who extracts stored LTK keys (physical access), clones a bonded device, or compromises firmware can bypass link-layer security.
Retrieval practice
Recall check 4 of 4
Radio Remi says: answer from memory, then check your reasoning.
Q5Place each BLE defense control where it lives so you can distinguish link protection from application authorization.
Show answer
Answer: A Place each control at its real boundary so you can see why secure pairing and encryption do not replace command-level authorization.
Q6Complete the authorization guard for a sensitive BLE command:
Show answer
Answer: A Sensitive commands should require both encrypted transport and fresh user authorization.
Print reference
Answers 1 of 2
Answer key.
- D · OOB uses a separate channel (e.g., NFC) to exchange pairing data, raising the bar for attackers because they must compromise both channels simultaneously.
- B · LE Secure Connections (BLE 4.2+) replaces legacy pairing with ECDH-based key agreement, providing protection against passive eavesdropping of pairing exchanges.
- C · Pairing creates the shared secrets for the current session; bonding persists them so trusted devices can reconnect securely without repeating the full pairing flow.
Print reference
Answers 2 of 2
Answer key.
- B · Even with encrypted BLE links, an attacker who extracts stored LTK keys (physical access), clones a bonded device, or compromises firmware can bypass link-layer security.
- A · Place each control at its real boundary so you can see why secure pairing and encryption do not replace command-level authorization.
- A · Sensitive commands should require both encrypted transport and fresh user authorization.