Link Layer

HEADER (2 Bytes)             PAYLOAD (0 - 251 Bytes)
+----------+-----------+---------------------------------------+
|          |           |                                       |
|  LLID    |  LENGTH   |         L2CAP PDU  (or Control Msg)   |
| (2 bits) | (6 bits)  |                                       |
|          |           |                                       |
+----------+-----------+---------------------------------------+
     ^           ^
     |           |
 01=Continuation |
 10=Start        Size of the
 11=Control      L2CAP packet

Context: If the PHY layer is the physical road, the Link Layer (LL) is the traffic control system. It decides who talks, when they talk, and how they maintain the connection. It sits directly above the PHY layer in the Controller.

For security researchers, the Link Layer is critical because it handles state transitions and control procedures. This is where connections are formed, parameters are negotiated, and importantly, where encryption is enabled (not negotiated, but enabled). Many "unpatchable" vulnerabilities (like BLEedingBit or Sweyntooth) exist here because this logic is burned into the Bluetooth Controller's firmware, not the application code.

---

1. The State Machine: Attack Surfaces at Every State

+-----------+
        |  STANDBY  | <----------------------------+
        +-----------+                              |
            |   |                                  |
 Start ADV  |   | Start SCAN                       | Disconnect
            v   v                                  |
+-----------+   +-----------+                      |
|ADVERTISING|   | SCANNING  | ----- Found ADV ---> |
+-----------+   +-----------+                      |
    |                 |                            |
    | "CONNECT_REQ"   | Initiate Connection        |
    | (Passive)       |                            |
    v                 v                            |
+---------------------------------------+          |
|             CONNECTED                 | ---------+
+---------------------------------------+
      (Master or Slave Role)

The Link Layer is defined by a state machine. A device can only be in one of five states at a time. Each state has unique vulnerabilities.

State	Function	Security Risk
Standby	Doing nothing.	Low risk (unless deep sleep exploits exist).
Advertising	Broadcasting packets on Ch 37-39.	Privacy Leakage: Broadcasting static MACs or UUIDs allows tracking. Spoofing: Anyone can mimic these packets.
Scanning	Listening for advertisers.	Malicious Advertisement Processing: A scanner parsing a malformed packet can crash (e.g., BleedingBit).
Initiating	Responding to an advertiser to start a connection.	MITM Opportunity: This is the moment to inject yourself between devices.
Connected	Active data transfer on Ch 0-36.	Injection/Hijacking: Once connected, if encryption isn't immediate, the link is vulnerable.

🛡️ Security Checks & Testing

• Fuzzing State Transitions: Use InternalBlue or Sweyntooth.

  • Test: Send malformed Link Layer Control Packets (LLCP) to a device in the Peripheral state.

  • Goal: Trigger a buffer overflow or crash in the controller firmware by sending unexpected packet lengths or opcodes.

---

2. Advertising & Scanning: The "Open Air" Phase

Before a connection exists, devices shout into the void. This is the Advertising phase.

• Channels: 37, 38, 39.

• Packet Type: ADV_IND (Connectable), ADV_NONCONN_IND (Beacon), etc.

• Scan Response: If a scanner asks (SCAN_REQ), the advertiser typically reveals more data (SCAN_RSP), often including the device name.

Security Perspective

Since these packets are unencrypted, any data inside is public. This includes manufacturer-specific data, which often contains unencrypted custom protocols or state information (e.g., "Smart Lock is Unlocked").

🛡️ Security Checks & Testing

• Passive Interception: Use bettercap or wireshark.

  • Test: Capture ADV_IND and SCAN_RSP packets. Decode the "Manufacturer Specific Data" field.

  • Goal: Look for varying bytes that correlate with device state (e.g., button presses, battery level).

• Active Cloning: Use hcitool a programmable dongle.

  • Test: Clone the MAC address and advertising payload of a target device.

  • Goal: See if the legitimate mobile app connects to your "fake" device instead of the real one.

---

3. Connection Establishment: The Critical Handshake

When a Central decides to connect, it sends a CONNECT_REQ. This packet is never encrypted and contains the blueprint for the entire connection:

1. Access Address (AA): The 32-bit session ID.

2. CRC Init: Seed for error checking.

3. Hop Increment & Interval: How the frequency hopping works.

Security Perspective

If you capture this one packet, you can follow the entire session. This is how sniffers work. If the connection does not immediately switch to an encrypted state (using a pre-bonded key), an attacker can inject packets.

🛡️ Security Checks & Testing

• Sniffing the Handshake: Use Sniffle (on TI CC2640/CC1352) or Ubertooth.

  • Test: Target an advertising device and wait for a connection.

  • Goal: Verify if you can capture the CONNECT_REQ. If yes, check how many packets pass before the LL_ENC_REQ (Encryption Request) is seen. If data flows before encryption, it's vulnerable.

---

4. Link Layer Control Protocol (LLCP): The Hidden Attack Surface

Once connected, devices use LLCP to manage the link. These are special packets with opcodes like LL_VERSION_IND, LL_PAUSE_ENC_REQ, LL_TERMINATE_IND.

Security Perspective

This is where low-level logic bugs live. Attacks like KNOB (Key Negotiation of Bluetooth) and BIAS (Bluetooth Impersonation Attack S) exploit this layer.

• KNOB: Forces the devices to negotiate a weak encryption key (1 byte entropy) by manipulating LLCP packets.

• Invalid Curve Attack: Exploits how the LL handles Elliptic Curve parameters during pairing.

🛡️ Security Checks & Testing

• KNOB Vulnerability Check:

  • Test: Use a tool that can manipulate LLCP (like certain firmware patches for Cypress/Broadcom chips or specialized test suites).

  • Goal: Force the LL_ENC_REQ to specify a minimum key size of 7 bytes (standard) or 1 byte (attack). If the device accepts 1 byte, it is vulnerable.

• Opcode Fuzzing:

  • Test: Send unexpected LLCP opcodes (e.g., sending a LL_LENGTH_REQ When encryption is paused.

  • Goal: Check for controller crashes (DoS).

---

5. Addressing: Privacy vs. Reality

BLE attempts to solve user tracking by using Resolvable Private Addresses (RPA). The MAC address changes periodically (e.g., every 15 minutes).

Security Perspective

RPA is often implemented poorly.

1. Identity Resolving Key (IRK): If an attacker gets the IRK (during pairing), they can resolve the random MAC back to the identity.

2. Timing Attacks: If the address changes but the payload data remains identical, the change is useless.

🛡️ Security Checks & Testing

• Address Randomization Audit:

  • Test: Monitor the device for 30 minutes. Does the MAC change?

  • Goal: When the MAC changes, does the payload content change too? If the MAC rotates but the "Manufacturer Data" stays constant, tracking is still trivial.

---

6. Connection State

Context: Unlike Wi-Fi, where an Access Point talks to many clients, most BLE Peripherals are "monogamous." They can only support one active connection at a time. Once a Central (phone/attacker) connects to a Peripheral, the Peripheral stops advertising. It effectively disappears from the world to talk to that one device.

The Attack (Connection Starvation):

1. Connect: The attacker connects to the target device.

2. Stall: The attacker does not pair, does not bond, and does not send data. They simply maintain the connection by responding to the Link Layer "Ping" (Connection Events).

3. Result: The device is now "busy." The legitimate owner walks up, tries to connect, and fails because the radio is occupied.

4. Persistence: If the device disconnects the attacker, the attacker creates a script to instantly reconnect (in milliseconds), permanently denying service to the owner.

Why it works: Developers often forget to implement an "Idle Timeout" or "Pairing Timeout." They assume a connection means a user is about to do something useful. If the firmware says, "Stay connected forever until the user disconnects," the attacker wins.

🛡️ Security Checks & Testing

• Starvation Test:

  • Tool: gatttool (Linux) or nRF Connect (Android).

  • Test: Connect to the device but do not pair/bond. Do nothing. Just leave the window open.

  • Observation:

    1. Does the device disconnect you automatically after 10-30 seconds? (Secure behavior).

    2. Or does it stay connected indefinitely? (Vulnerable).

  • Verification: While connected with the attacker machine, try to find/connect to the device with the legitimate mobile app. It should be invisible or unreachable.