Lab: Bluetooth & the Connected Car

This lab makes the Connected Car attack-surface map tangible. You will observe — with a few lines of Python — how everyday devices, and even a car, announce themselves over Bluetooth Low Energy (BLE). Then we study the single most instructive car-security story of the last few years: the two-person relay attack on a phone-as-key, and why a car with flawless cryptography could still be opened.

The point of contrast is the lesson. A ₹600 smart bulb lets anyone connect and flip it. A car’s phone-key does not — and seeing why is worth more than any exploit.

Rules of engagement — read before you touch anything

This lab is passive observation only, on devices and vehicles you own or are explicitly authorized to test.

• Scanning (listening for advertisements) is safe and is all the hands-on work here.
• Do not attempt to relay, replay, unlock, start, or interfere with any vehicle — yours or anyone else’s. That is theft tooling, not a lab, and we neither build nor demonstrate it.
• The relay attack below is taught as a diagram and walkthrough only.
• Authorized ways to go deeper: your own vehicle with written consent, automotive CTFs, and manufacturer bug-bounty programs with responsible disclosure.

Part A · Observe how BLE devices advertise (hands-on)

Setup

python3 -m venv bt-lab && source bt-lab/bin/activate
pip install bleak          # cross-platform BLE: macOS, Linux, Windows

On Windows?

Run this lab with native Windows Python (pip install bleak) — not in WSL, which can’t see your Bluetooth radio. bleak uses the Windows Bluetooth stack directly; grant Bluetooth permission if prompted. See Windows Setup.

On macOS, grant your terminal Bluetooth permission (System Settings → Privacy & Security → Bluetooth) or scans return nothing. On Linux, bleak uses the built-in BlueZ stack.

Step 1 — Scan for nearby devices

1. Save this as scan.py:

   # scan.py — list advertising BLE devices, strongest signal first
   import asyncio
   from bleak import BleakScanner
   
   async def main():
       print("Scanning for 8s…\n")
       found = await BleakScanner.discover(timeout=8.0, return_adv=True)
       for addr, (dev, adv) in sorted(
           found.items(), key=lambda kv: kv[1][1].rssi, reverse=True
       ):
           name = dev.name or adv.local_name or "(no name)"
           print(f"{addr}  RSSI {adv.rssi:>4} dBm  {name}")
           if adv.service_uuids:
               print(f"      services: {', '.join(adv.service_uuids)}")
   
   asyncio.run(main())

2. Run it in a room with a few of your own devices powered on:

   python scan.py

3. Observe: every device’s address, its signal strength (RSSI — higher/closer to 0 means nearer), its broadcast name (often a giveaway), and the services it advertises before any connection. That last column is the lesson: devices announce their capabilities to anyone listening. This is free reconnaissance.

Step 2 — Walk toward your own car

If someone in the room owns a car with a phone-key (a Tesla is the classic example), run scan.py and walk toward it. You will see a device advertising a vehicle service, and its RSSI climb as you approach. That is all we do to the car — watch it announce itself. Reconnaissance is effortless; that fact alone is worth sitting with.

Step 3 — The contrast that matters

Now compare what happens if you try to go further (on hardware you own). Enumerating a device’s GATT table — its services and characteristics — reveals whether it actually protects itself:

# enumerate.py — connect to YOUR device and list what it exposes
import asyncio, sys
from bleak import BleakClient

async def main(address):
    async with BleakClient(address) as client:
        print("connected:", client.is_connected, "\n")
        for service in client.services:
            print(f"[service] {service.uuid}")
            for ch in service.characteristics:
                print(f"   └ {ch.uuid}  ({', '.join(ch.properties)})")

asyncio.run(main(sys.argv[1]))   # python enumerate.py AA:BB:CC:DD:EE:FF

	Cheap IoT gadget (bulb, beacon)	Car phone-key (e.g. Tesla)
Connect	open — no pairing needed	connects at the link layer, but…
Read / write control	plaintext characteristics	authenticated, encrypted challenge-response
Keys	none, or hardcoded	per-session keys; public-key cryptography
”Just connect and write a value”	the light changes	nothing — unsigned commands are rejected

The takeaway

The car did the fundamentals right. You can connect, but you cannot read or forge a control command, because every instruction must be cryptographically signed by the enrolled key. The bulb is a pushover precisely because it skipped this. Authentication is the difference.

Part B · The two-person relay attack (case study — diagram only)

If the cryptography can’t be broken, how were these phone-keys ever defeated? Not by breaking the math — by breaking an assumption. The key-exchange treats “the phone is physically near the car” as part of the proof of trust. But nearness is inferred from a radio signal, and a radio signal can be relayed.

This is the 2022 NCC Group BLE relay attack (researcher Sultan Qasim Khan), the canonical demonstration. Two attackers with relay devices form a “bucket brigade”:

The encrypted exchange is passed through untouched — only the distance it assumes is faked.

Walked through step by step:

1. Relay B stands near the locked car and wakes it. The car issues a cryptographic challenge — “prove you hold the enrolled key.”
2. That challenge is carried over a long-range link (Wi-Fi/internet) to Relay A, which is near the owner’s phone — possibly streets or kilometres away.
3. The real phone receives the challenge and signs it correctly. It has no way to know it is far from the car; the request looks completely legitimate.
4. The signed reply is relayed back to the car, which verifies it perfectly and unlocks. The attackers never saw a key and never broke a cipher — they only extended the distance the protocol assumed was short.

Why this matters conceptually

A system can have perfect encryption and still fail, because security rests on assumptions about the real world, not just on algorithms. This is the foundations lesson made physical: threat modeling means asking “what does this design quietly assume?” Here, the assumption was proximity — and proximity was forgeable.

Part C · How the relay is defeated

The fix is not “more cryptography.” It is removing the assumptions the relay abuses, and adding a second independent layer.

Distance-bounding removes the abused assumption; PIN-to-Drive adds a layer a relay can’t cross.

• Ultra-Wideband (UWB) distance bounding. Newer phone-keys measure the signal’s true round-trip time of flight to compute the real distance. A relay can only add delay (it can never make light travel faster), so a relayed key looks “too far” and the unlock is refused. This is the direct, principled counter to a relay.
• PIN-to-Drive (defense in depth). Even if doors are opened, driving away requires a secret PIN the attackers do not have. One bypassed layer does not become a stolen car — the same defense-in-depth principle from the foundations.
• Owner hygiene. Disable passive entry, enable PIN-to-Drive, and keep keys in a signal-blocking pouch.

Debrief

Bring it back to the map and the course:

• On the Connected Car map, this whole story lives at pin #1 (key-fob / phone-key relay) — now you know exactly how that pin breaks and how it’s closed.
• Compare the effort: passive reconnaissance was trivial; defeating an authenticated system required attacking an assumption, not the crypto.
• Ask the room: what else trusts “it’s nearby” as if it were “it’s authorized”? (Hotel keycards, contactless payments, office badges…)
• The ethical close ties to the post-Mythos world: the people who find flaws like this report them — NCC Group disclosed responsibly, and the defenses above exist because of it. That is the Year of the Defender in practice.