Seguridad en Bluetooth

Introducción a Bluetooth

Bluetooth es un estándar de comunicación inalámbrica de corto alcance, desarrollado bajo el paraguas del Bluetooth Special Interest Group (SIG), una asociación formada por empresas como Ericsson, IBM, Intel, Nokia y Toshiba. El nombre proviene de Harald Bluetooth, rey vikingo de Dinamarca (siglo X), conocido por unificar tribus escandinavas, una metáfora del objetivo del protocolo: unificar las comunicaciones entre dispositivos heterogéneos.

Desde su primera especificación, Bluetooth ha evolucionado enormemente (de 1.0 a 5.4), pero sus mecanismos de seguridad fundamentales arrastran decisiones de diseño que, combinadas con implementaciones deficientes, generan una superficie de ataque significativa.

Especificaciones técnicas

Tecnología de radio

Bluetooth opera en la banda ISM de 2.4 GHz (sin licencia, disponible globalmente). Las características principales son:

• Alcance nominal: 10 cm a 10 m (Clase 2), extensible a 100 m (Clase 1) incrementando la potencia de transmisión
• Frecuencia: 2.402 - 2.480 GHz, con frequency hopping (salto de frecuencia) a 1600 saltos/segundo entre 79 canales
• Velocidad: desde 721 Kbps (Bluetooth 1.x) hasta 3 Mbps (Bluetooth 3.0 + HS) y 2 Mbps (BLE 5.0)
• Topología: piconets (1 maestro + hasta 7 esclavos activos), agrupables en scatternets

Pila de protocolos

La pila Bluetooth combina protocolos propios con estándares existentes para maximizar la interoperabilidad:

• Banda Base + LMP (Link Manager Protocol): gestiona el enlace físico, establecimiento de conexión, autenticación y cifrado
• HCI (Host Controller Interface): interfaz de comandos entre el software del host y el hardware Bluetooth
• L2CAP (Logical Link Control and Adaptation Protocol): multiplexación, segmentación y reensamblaje de paquetes (hasta 64 KB)
• RFCOMM: emulación de puertos serie sobre L2CAP, soporta hasta 60 conexiones simultáneas
• SDP (Service Discovery Protocol): descubrimiento de servicios disponibles en dispositivos remotos
• OBEX (Object Exchange): transferencia de archivos y objetos (heredado de IrDA)

Descubrimiento de dispositivos (HCI Inquiry)

El mecanismo de descubrimiento utiliza el comando HCI inquiry para localizar dispositivos en modo visible:

# 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

El campo BD_ADDR es la dirección MAC única del dispositivo Bluetooth (48 bits). El campo Class codifica el tipo de dispositivo y sus capacidades.

Protocolo L2CAP

L2CAP proporciona la capa de transporte para protocolos superiores. Podemos inspeccionar conexiones L2CAP activas:

# 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

Descubrimiento de servicios (SDP)

SDP permite al cliente descubrir qué servicios ofrece un servidor Bluetooth, incluyendo tipo de servicio, protocolo de transporte y canal:

# 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

Perfiles Bluetooth

Los perfiles definen cómo utilizar la pila de protocolos para casos de uso concretos, garantizando la interoperabilidad entre fabricantes. Los más relevantes para seguridad son:

• DUN (Dial-Up Networking): permite usar un teléfono como módem inalámbrico
• SPP (Serial Port Profile): emulación de puerto serie, base para comandos AT
• OPUSH (Object Push): envío de archivos via OBEX (tarjetas de visita, archivos)
• FTP (File Transfer Profile): acceso al sistema de archivos del dispositivo
• HFP/HSP (Handsfree/Headset): perfiles de audio

Mecanismos de seguridad

Modos de seguridad

La especificación Bluetooth define cuatro modos de seguridad (tres en las versiones clásicas):

• Modo 1 (Sin seguridad): autenticación y cifrado deshabilitados. El dispositivo acepta conexiones de cualquier origen. Es el modo más peligroso.
• Modo 2 (Seguridad a nivel de servicio): la seguridad se aplica después de establecer el canal L2CAP. Un gestor de seguridad controla el acceso por servicio. Permite que servicios con diferentes requisitos de seguridad coexistan.
• Modo 3 (Seguridad a nivel de enlace): la autenticación y el cifrado se inician antes de establecer cualquier canal. Todo ocurre dentro del chip Bluetooth. Incluye autenticación PIN, seguridad MAC y cifrado.
• Modo 4 (SSP): introducido en Bluetooth 2.1, usa Secure Simple Pairing con criptografía de curva elíptica (ECDH). Mejora significativamente la protección contra ataques pasivos.

Emparejamiento (Pairing)

El emparejamiento es el proceso mediante el cual dos dispositivos establecen una relación de confianza. En Bluetooth clásico (pre-2.1), el proceso funciona así:

1. Ambos usuarios introducen el mismo código PIN (cadena ASCII de 1 a 16 caracteres)
2. Se genera una clave de inicialización (K_init) mediante el algoritmo E22, usando el PIN, la longitud del PIN, la BD_ADDR y un número aleatorio IN_RAND
3. Se intercambian números aleatorios (LK_RAND_A y LK_RAND_B) protegidos por XOR con K_init
4. El algoritmo E21 genera la clave de enlace (K_ab) definitiva a partir de los valores intercambiados
5. La clave de enlace se almacena para futuros usos (no es necesario repetir el emparejamiento)

Autenticación (Challenge-Response)

Una vez generada la clave de enlace, la autenticación sigue un esquema challenge-response:

1. El demandante envía su BD_ADDR (48 bits) al verificador
2. El verificador envía un desafío aleatorio AU_RAND (128 bits)
3. Ambos dispositivos aplican el algoritmo E1 usando BD_ADDR, K_ab y AU_RAND
4. El demandante envía su resultado SRES (32 bits) al verificador
5. Si los valores coinciden, la autenticación es exitosa

Durante este proceso se genera además el ACO (Authenticated Ciphering Offset) de 96 bits, necesario para la generación de la clave de cifrado.

Cifrado con E0

Cuando el Link Manager activa el cifrado, se genera una clave de cifrado (K_c) mediante el algoritmo E3, usando la clave de enlace, un número aleatorio de 128 bits y el ACO. El cifrado real lo realiza el algoritmo E0, un cifrador de flujo (stream cipher) basado en cuatro registros LFSR (Linear Feedback Shift Registers) de 25, 31, 33 y 39 bits (128 bits en total).

El proceso de cifrado:

1. El maestro envía un número aleatorio RAND al esclavo
2. Antes de cada paquete, los LFSR se inicializan combinando RAND, la BD_ADDR del maestro, K_c y el reloj (número de slot)
3. Se genera un keystream que se aplica XOR con los datos del payload
4. Cada paquete usa una clave diferente (gracias al reloj cambiante)

La longitud de la clave de cifrado es negociable entre 8 y 128 bits, lo cual ya es una debilidad en sí misma.

Vulnerabilidades y debilidades

Debilidades de diseño

• PINs cortos permitidos: los usuarios tienden a usar PINs de 4 dígitos o menos, lo que reduce drásticamente el espacio de claves
• Generador pseudoaleatorio no verificado: podría producir secuencias predecibles o repetitivas
• Distribución de PINs no estandarizada: en redes Bluetooth grandes, gestionar PINs es problemático
• Longitud de clave negociable: un atacante podría forzar una longitud de clave débil (ataque KNOB)
• Clave maestra compartida en modo 3: compromete la confidencialidad entre esclavos
• Solo autenticación de dispositivos: no existe autenticación de usuarios
• Sin límite de intentos de autenticación: permite ataques de fuerza bruta
• Vulnerable a Man-in-the-Middle: el esquema challenge-response con hashes no protege contra MITM

Vulnerabilidades del cifrado E0

Aunque E0 se consideraba razonablemente seguro en sus inicios, los ataques han ido mejorando:

• Jakobsson y Wetzel: redujeron la complejidad efectiva de 128 a 100 bits — O(2^100)
• Fluhrer y Lucks: O(2^73) a O(2^84), dependiendo del keystream capturado (aunque requería ~14 TB de keystream)
• Yi Lu y Serge Vaudenay (2004): O(2^37) con 64 GB de keystream consecutivo, mejorado a O(2^40) con solo los primeros 24 bits de 2^35 frames

Además:

• Uso parcial del reloj: el bit más significativo del reloj del maestro se ignora, facilitando ataques MITM
• Datos cifrados manipulables: las propiedades del cifrado de flujo permiten modificar datos interceptados (por ejemplo, cabeceras IP) si se conoce parte del texto claro

Vulnerabilidades de implementación

Más allá de las debilidades teóricas, las implementaciones reales presentan fallos graves:

• Permisos IrMC mal configurados: objetos accesibles sin emparejamiento, servicios abiertos intencionadamente
• Errores de pila: buffer overflows, falta de verificación de longitud en OBEX, problemas con terminadores NULL
• Servicios ocultos: servicios con privilegios elevados que no aparecen en SDP pero están activos — canales traseros para facilitar la comunicación entre dispositivos del mismo fabricante, que proporcionan acceso completo a comandos AT

Ataques históricos relevantes

La combinación de estas debilidades ha dado lugar a ataques bien documentados:

• BlueBug: acceso completo al dispositivo vía comandos AT a través de un canal RFCOMM oculto
• BlueSnarf: acceso no autorizado a archivos vía OBEX Push sin autenticación
• BlueSnarf++: acceso completo al sistema de archivos vía OBEX FTP
• Blooover: explotación de BlueBug desde un dispositivo J2ME
• Car Whisperer: acceso a manos libres de automóviles usando PINs por defecto (0000/1234)
• KNOB Attack (2019): fuerza la negociación de claves de cifrado de 1 byte, permitiendo descifrado en tiempo real
• BIAS Attack (2020): elude la autenticación en dispositivos previamente emparejados
• BrakTooth (2021): familia de vulnerabilidades en pilas Bluetooth comerciales que causan desde DoS hasta ejecución de código

Recomendaciones de seguridad

Para minimizar los riesgos de seguridad en Bluetooth:

• Desactivar Bluetooth cuando no se esté utilizando
• Configurar el dispositivo como no visible (no es suficiente por sí solo, pero reduce la superficie)
• Usar PINs largos y complejos durante el emparejamiento
• Rechazar solicitudes de emparejamiento inesperadas
• Mantener el firmware actualizado para parchear vulnerabilidades conocidas
• Preferir dispositivos con Bluetooth 4.2+ que implementen LE Secure Connections con ECDH
• En entornos corporativos, considerar políticas de gestión de dispositivos Bluetooth
• Auditar periódicamente los servicios expuestos en dispositivos críticos

La seguridad Bluetooth ha mejorado significativamente con cada versión del estándar, pero la retrocompatibilidad con versiones antiguas y las implementaciones deficientes siguen siendo un vector de ataque real.

:wq!