Bluetooth security

Introduction to Bluetooth

Bluetooth is a short-range wireless communication standard, developed under the umbrella of the Bluetooth Special Interest Group (SIG), an association formed by companies such as Ericsson, IBM, Intel, Nokia and Toshiba. The name comes from Harald Bluetooth, Viking king of Denmark (10th century), known for unifying Scandinavian tribes, a metaphor for the protocol's goal: unifying communications between heterogeneous devices.

Since its first specification, Bluetooth has evolved enormously (from 1.0 to 5.4), but its fundamental security mechanisms carry design decisions that, combined with poor implementations, create a significant attack surface.

Technical specifications

radio technology

Bluetooth operates in the ISM band 2.4GHz (license-free, available globally). The main features are:

• Nominal range: 10 cm to 10 m (Class 2), extendable to 100 m (Class 1) increasing transmission power
• Frequency: 2.402 - 2.480 GHz, with frequency hopping (frequency hopping) at 1600 hops/second between 79 channels
• Speed: from 721 Kbps (Bluetooth 1.x) to 3 Mbps (Bluetooth 3.0 + HS) and 2 Mbps (BLE 5.0)
• Topology: piconets (1 master + up to 7 active slaves), groupable into scatternets

Protocol stack

The Bluetooth stack combines proprietary protocols with existing standards to maximize interoperability:

• Baseband + LMP (Link Manager Protocol): manages the physical link, connection establishment, authentication and encryption
• HCI (Host Controller Interface): Command interface between the host software and the Bluetooth hardware
• L2CAP (Logical Link Control and Adaptation Protocol): packet multiplexing, segmentation and reassembly (up to 64 KB)
• RFCOMM: emulation of serial ports over L2CAP, supports up to 60 simultaneous connections
• SDP (Service Discovery Protocol): discovery of services available on remote devices
• OBEX (Object Exchange): file and object transfer (legacy from IrDA)

Device Discovery (HCI Inquiry)

The discovery mechanism uses the HCI command inquiry To locate devices in visible mode:

# Escaneo de dispositivos Bluetooth cercanos
hcitool scan
# Scanning ...
#   00:80:37:29:19:A4   Nokia-N8
#   BD Address: 00:80:37:29:19:A4
#   Page Scan Rep. Mode: 0x1
#   Class: 52:02:04
#   Clock offset: 0x78ef

The field BD_ADDR is the unique MAC address of the Bluetooth device (48 bits). The field Class encodes the type of device and its capabilities.

L2CAP protocol

L2CAP provides the transport layer for higher protocols. We can inspect active L2CAP connections:

# En Linux, verificar conexiones L2CAP
hcitool con
# Connections:
#   < ACL 00:80:37:29:19:A4 handle 41 state 1 lm MASTER

# Información detallada de la conexión
hcitool info 00:80:37:29:19:A4

Service Discovery (SDP)

SDP allows the client to discover what services a Bluetooth server offers, including service type, transport protocol and channel:

# Navegar todos los servicios de un dispositivo
sdptool browse 00:80:37:29:19:A4
# Service Name: LAN Access Using PPP
# Service Class ID List:
#   LAN Access Using PPP (0x1102)
# Protocol Descriptor List:
#   L2CAP (0x0100)
#   RFCOMM (0x0003) - Channel: 1
# Profile: LAN Access Using PPP (0x1102) ver. 1.0

# Buscar un servicio específico
sdptool search OPUSH 00:80:37:29:19:A4

Bluetooth profiles

The profiles They define how to use the protocol stack for specific use cases, guaranteeing interoperability between manufacturers. The most relevant for security are:

• DUN (Dial-Up Networking): Allows you to use a phone as a wireless modem
• SPP (Serial Port Profile): serial port emulation, base for AT commands
• OPUSH (Object Push): sending files via OBEX (business cards, files)
• FTP (File Transfer Profile): access to the device's file system
• HFP/HSP (Handsfree/Headset): Audio profiles

Security mechanisms

Security modes

The Bluetooth specification defines four security modes (three in classic versions):

• Mode 1 (No security)- Authentication and encryption disabled. The device accepts connections from any source. It is the most dangerous way.
• Mode 2 (Service Level Security)- Security is applied after establishing the L2CAP channel. A security manager controls access by service. It allows services with different security requirements to coexist.
• Mode 3 (Link Level Security)- Authentication and encryption are started before any channel is established. It all happens inside the Bluetooth chip. Includes PIN authentication, MAC security and encryption.
• Mode 4 (SSP): introduced in Bluetooth 2.1, use Secure Simple Pairing with elliptic curve cryptography (ECDH). Significantly improves protection against passive attacks.

Pairing

Pairing is the process by which two devices establish a trusting relationship. In classic Bluetooth (pre-2.1), the process works like this:

1. Both users enter the same code PIN (ASCII string of 1 to 16 characters)
2. It generates a initialization key (K_init) using the E22 algorithm, using the PIN, the PIN length, the BD_ADDR and a random number IN_RAND
3. Random numbers are exchanged (LK_RAND_A and LK_RAND_B) protected by XOR with K_init
4. The E21 algorithm generates the link key (K_ab) definitive from the exchanged values
5. The link key is stored for future use (no need to repeat pairing)

Authentication (Challenge-Response)

Once the link key is generated, authentication follows a scheme challenge-response:

1. He demanding send your BD_ADDR (48 bits) to the verifier
2. He checker send a random challenge AU_RAND (128 bit)
3. Both devices apply the algorithm E1 wearing BD_ADDR, K_ab and AU_RAND
4. The plaintiff sends his result SRES (32 bits) to verifier
5. If the values ​​match, the authentication is successful

During this process, the ACO (Authenticated Ciphering Offset) 96 bits, necessary for generating the encryption key.

Encryption with E0

When the Link Manager activates encryption, a encryption key (K_c) using the E3 algorithm, using the link key, a 128-bit random number and the ACO. The actual encryption is done by the algorithm E0, a stream cipher (stream cipher) based on four LFSR registers (Linear Feedback Shift Registers) of 25, 31, 33 and 39 bits (128 bits in total).

The encryption process:

1. The teacher sends a random number RAND to the slave
2. Before each packet, the LFSRs are initialized by combining RAND, the BD_ADDR of the teacher, K_c and the clock (slot number)
3. It generates a keystream that XOR is applied with the payload data
4. Each packet uses a different key (thanks to the changing clock)

The length of the encryption key is negotiable between 8 and 128 bits, which is a weakness in itself.

Vulnerabilities and weaknesses

Design weaknesses

• Short PINs allowed- Users tend to use PINs of 4 digits or less, which dramatically reduces key space
• Unverified pseudorandom generator: could produce predictable or repetitive sequences
• Non-standardized PIN distribution- In large Bluetooth networks, managing PINs is problematic
• Negotiable key length- An attacker could force a weak key length (attack KNOB)
• Shared master key in mode 3: compromises confidentiality between slaves
• Device authentication only: no user authentication exists
• No limit on authentication attempts- Allows brute force attacks
• Vulnerable to Man-in-the-Middle: challenge-response scheme with hashes does not protect against MITM

E0 encryption vulnerabilities

Although E0 was considered reasonably secure in its early days, attacks have been improving:

• Jakobsson and Wetzel: reduced the effective complexity from 128 to 100 bits — O(2^100)
• Fluhrer and Lucks: O(2^73) to O(2^84), depending on the captured keystream (although it required ~14 TB of keystream)
• Yi Lu and Serge Vaudenay (2004): O(2^37) with 64 GB of consecutive keystream, improved to O(2^40) with only the first 24 bits of 2^35 frames

Besides:

• Partial use of the watch: the most significant bit of the master clock is ignored, facilitating MITM attacks
• Manipulated encrypted data- Stream cipher properties allow intercepted data (e.g. IP headers) to be modified if part of the cleartext is known

Implementation vulnerabilities

Beyond the theoretical weaknesses, real implementations have serious flaws:

• Misconfigured IrMC permissions: objects accessible without pairing, services opened intentionally
• Stack errors: buffer overflows, lack of length checking in OBEX, problems with NULL terminators
• Hidden services: Elevated services that do not appear in SDP but are active — back channels to facilitate communication between devices from the same manufacturer, providing full access to AT commands

Relevant historical attacks

The combination of these weaknesses has led to well-documented attacks:

• BlueBug- Full access to the device via AT commands over a hidden RFCOMM channel
• BlueSnarf: unauthorized access to files via OBEX Push without authentication
• BlueSnarf++: full access to the file system via OBEX FTP
• Blooover- Exploiting BlueBug from a J2ME device
• Car Whisperer: Hands-free car access using default PINs (0000/1234)
• KNOB Attack (2019)- Forces negotiation of 1-byte encryption keys, allowing real-time decryption
• BIAS Attack (2020)– Bypass authentication on previously paired devices
• BrakTooth (2021)- family of vulnerabilities in commercial Bluetooth stacks causing everything from DoS to code execution

Security recommendations

To minimize security risks in Bluetooth:

• Turn off Bluetooth when not in use
• Set the device as not visible (not enough on its own, but reduces surface area)
• Use long and complex PINs during pairing
• Reject unexpected pairing requests
• Keep firmware updated to patch known vulnerabilities
• Prefer devices with Bluetooth 4.2+ implement LE Secure Connections with ECDH
• In corporate environments, consider Bluetooth device management policies
• Periodically audit exposed services on critical devices

Bluetooth security has improved significantly with each version of the standard, but backwards compatibility and poor implementations remain a real attack vector.

:wq!