RF-201 Week 5 — Bluetooth Classic + BLE Protocol RE

"Bluetooth's security model is often described as 'security by obscurity' — an unfair characterisation. The FHSS is not obscurity; the pairing models are not obscurity. But the assumption that passive observation is difficult enough to forgo link-layer encryption in some modes — that is a policy choice, and policy choices have consequences."

Lecture (90 min)

5.1 Bluetooth Architecture: Two Protocols in One Brand

"Bluetooth" names two separate wireless technologies that share a brand and a chipset:

They coexist in "Bluetooth 5.x" chipsets (a combo chip). From a security perspective they have largely separate stacks, separate pairing models, and separate vulnerability profiles. WIR-101 Lab 8 introduced both; RF-201 opens each.

5.2 Bluetooth Classic (BR/EDR)

Physical layer: FHSS across 79 channels (1 MHz spacing; 2.402-2.480 GHz). Hop rate: 1600 hops/second. Each 625 µs slot is one hop.

Modulation:

• BR (Basic Rate, 1 Mbps): GFSK with deviation ±160 kHz, BT=0.35
• EDR (Enhanced Data Rate):
  • 2 Mbps: π/4-DQPSK
  • 3 Mbps: 8-DPSK

Architecture layers:

Application (profiles: HFP, A2DP, HID, SPP, FTP...)
    ↑
RFCOMM (serial port emulation)
    ↑
L2CAP (Logical Link Control and Adaptation Protocol)
    ↑
HCI (Host Controller Interface — the software/hardware boundary)
    ↑
Baseband / Link Manager (LMP — Link Manager Protocol)
    ↑
Physical (RF; FHSS; BR/EDR)

Inquiry and paging: An unconnected device broadcasts at 32 hops/s on inquiry-scan channels. The inquiring device listens. Inquiry responses contain: BD_ADDR (48-bit address), clock offset, class of device. BD_ADDR is a MAC-style identifier. It is always broadcast unencrypted during inquiry.

Pairing — the four models:

SSP (Secure Simple Pairing) uses Elliptic Curve Diffie-Hellman (P-192 in BT 2.1-4.x; P-256 in BT 5.1+). The shared secret is used to derive the link key. After pairing, link-layer encryption uses AES-CCM (BT 4.1+).

The key security implication: The hop sequence is deterministic from the master's BD_ADDR and clock. An attacker who captures BD_ADDR (trivial from inquiry) and estimates the clock can compute all future hop frequencies. Ubertooth One tools include ubertooth-follow which does exactly this.

5.3 BLE (Bluetooth Low Energy)

Physical layer: 40 channels (2 MHz spacing). 3 advertising channels (37: 2.402 GHz, 38: 2.426 GHz, 39: 2.480 GHz chosen to avoid WiFi overlap). 37 data channels.

BLE is not FHSS in the same way: BLE uses adaptive frequency hopping on data channels. The hopping sequence is derived from the connection access address (random 32-bit per connection) and a hop increment. An attacker who does not know the access address cannot follow data channels — a meaningful improvement over Bluetooth Classic's predictable hop sequence.

BLE advertising: Devices advertise on all 3 advertising channels. An advertising PDU contains: AdvA (the device's 48-bit address), AdvData (up to 31 bytes; RSSI, services, manufacturer data). Advertising addresses may be public (permanent, OUI-based) or random (resolvable or non-resolvable). Resolvable private addresses rotate periodically and can only be tracked if you have the device's Identity Resolving Key (IRK).

GATT (Generic Attribute Profile): The application-layer data model. A GATT server exposes a hierarchy of:

• Services: groups of related characteristics (identified by 16-bit or 128-bit UUID)
• Characteristics: individual data points (a value + properties: read/write/notify/indicate)
• Descriptors: metadata about characteristics (CCCD: Client Characteristic Configuration Descriptor — enables notifications)

In WIR-101 Lab 8 you enumerated GATT using gatttool. RF-201 goes deeper: authenticated pairing + encryption + descriptor writes.

BLE pairing models:

BLE security levels:

Most consumer BLE IoT devices operate at Level 1 or 2. Security researchers routinely find characteristics at Level 1 that should be Level 3+.

5.4 Protocol RE Workflow: Bluetooth Classic + BLE

Goal: Given an authorised target device (your own or an instructor-placed lab device), characterise:

1. Is it BR/EDR, BLE, or dual-mode?
2. What services/profiles/characteristics are exposed?
3. What authentication and encryption are in use?
4. What does an authenticated exchange look like in the raw LMP/HCI/ATT trace?

Tools:

BLE enumeration in Python (bleak library):

import asyncio
from bleak import BleakScanner, BleakClient

async def enumerate_ble_device(address):
    async with BleakClient(address) as client:
        services = await client.get_services()
        for service in services:
            print(f"Service: {service.uuid}")
            for char in service.characteristics:
                print(f"  Char: {char.uuid}  Props: {char.properties}")
                if 'read' in char.properties:
                    try:
                        val = await client.read_gatt_char(char)
                        print(f"    Value: {val.hex()}")
                    except Exception as e:
                        print(f"    Read error: {e}")

# Find device addresses first
async def scan():
    devices = await BleakScanner.discover(timeout=5.0)
    for d in devices:
        print(d.address, d.name, d.rssi)

asyncio.run(scan())
# asyncio.run(enumerate_ble_device("AA:BB:CC:DD:EE:FF"))

Homework

Reading (1.5 hr):

• Bluetooth Core Specification Vol 3, Part H (Security Manager Protocol) §2.1-2.3 — free PDF at bluetooth.com
• PySDR Ch 8 (Channel Models) — AWGN + fading models apply to BLE SNR analysis
• Wyglinski Ch 4 §4.3-4.4 (link-layer framing; error correction)

Hands-on (2 hr): Install bleak and scan for BLE devices in your environment. For any device you personally own (phone in developer mode, fitness tracker, smart bulb):

1. Enumerate all GATT services and characteristics
2. Identify which characteristics are readable without pairing
3. Note the UUID and attempt to decode the value against the Bluetooth GATT specification UUIDs (bluetooth.com/specifications/assigned-numbers)

Write a 1-page observation: what did you find, what was readable without authentication, and what security level(s) are in use?

Key Terms

• BD_ADDR: Bluetooth device address; 48-bit; analogous to MAC; broadcast in inquiry; first 3 bytes are OUI
• GFSK (Gaussian-filtered FSK): Bluetooth Classic's physical-layer modulation; Gaussian filter smooths symbol transitions to reduce spectral splatter
• SSP (Secure Simple Pairing): Bluetooth 2.1+ pairing protocol; ECDH key exchange; four association models; replaces legacy PIN
• Just Works: SSP/BLE pairing model with no user verification; convenient but MITM-vulnerable
• Access address: BLE per-connection 32-bit random number used to derive hopping sequence; provides channel privacy
• GATT (Generic Attribute Profile): BLE application-layer data model; services + characteristics + descriptors
• CCCD (Client Characteristic Configuration Descriptor): BLE descriptor that enables characteristic notifications/indications; write 0x0100 to enable notification
• bleak: Python BLE library for cross-platform central-role operations; asyncio-based