Captura y descifrado de tráfico Bluetooth de baja energía (BLE)

Introducción

El protocolo Bluetooth Low Energy (BLE) se ha convertido en un estándar fundamental dentro del ecosistema IoT, utilizado en wearables, sensores, periféricos y una gran variedad de dispositivos conectados. Es posible capturar y analizar su tráfico en tiempo real utilizando hardware dedicado. Para ello, el nRF52840 Dongle de Nordic Semiconductor, junto con la herramienta nRF Sniffer for Bluetooth LE, constituye una solución accesible y potente. Se instalará el firmware necesario en el dongle, se integrará el sniffer en un entorno Linux y se capturará tráfico BLE en Wireshark. También se abordan tres escenarios de análisis con distintos niveles de seguridad: conexiones sin emparejamiento, emparejamiento clásico vulnerable (Legacy Pairing) y emparejamiento moderno y robusto basado en curvas elípticas (LE Secure Connections).

Instalación del firmware del Sniffer en el nRF52840 Dongle

Para comenzar, es necesario preparar el nRF52840 Dongle instalando un firmware especial que le permite funcionar como sniffer BLE. Lo primero es poner el dongle en modo DFU. Esto se hace conectándolo al puerto USB del ordenador y pulsando el botón RESET que incorpora. El LED del dispositivo comenzará a parpadear en color rojo, señal de que ha entrado en modo bootloader. Se utilizará la herramienta nrfutil, por lo que descargamos el binario junto a la sub-herramienta ble-sniffer y device.

$ curl https://files.nordicsemi.com/artifactory/swtools/external/nrfutil/executables/x86_64-unknown-linux-gnu/nrfutil -o nrfutil
$ chmod +x nrfutil
$ ./nrfutil install ble-sniffer

A continuación comprobaremos que el dispositivo se encuentra conectado con el comando device list. Si el dispositivo que aparece es Open DFU Bootloader, podremos continuar confirmando que el dispositivo se encuentra en modo DFU.

$ ./nrfutil device list
A1234B5678C9
Product         Open DFU Bootloader
Ports           /dev/ttyACM0
Traits          nordicDfu, nordicUsb, serialPorts, usb

Supported devices found: 1

Tomamos nota del número de serie de dispositivo que aparece en la primera línea, en este caso A1234B5678C9 para proceder con la instalación del firmware con el comando device program. En este caso las sub-herramientas de nrfutil se han instalado en el directorio ~/.nrfutil, y los firmware se encuentran en la carpeta .nrfutil/share/nrfutil-ble-sniffer/firmware/.

$ ls .nrfutil/share/nrfutil-ble-sniffer/firmware/
sniffer_nrf52833dk_nrf52833_4.1.1.hex
sniffer_nrf52840dongle_nrf52840_4.1.1.zip
sniffer_nrf52840dk_nrf52840_4.1.1.hex
sniffer_nrf52dk_nrf52832_4.1.1.hex

En este caso, al tratarse de un nRF52840 Dongle (modelo PCA10059), instalamos el firmware sniffer_nrf52840dongle_nrf52840_4.1.1.zip.

./nrfutil device program --serial-number A1234B5678C9 --firmware .nrfutil/share/nrfutil-ble-sniffer/firmware/sniffer_nrf52840dongle_nrf52840_4.1.1.zip

Tras la instalación correcta, se desconectará y reconectará el dispositivo con el objetivo de que se cargue el nuevo firmware. Al actualizar la lista de dispositivos encontraremos el dispositivo nRF Sniffer for Bluetooth LE.

$ ./nrfutil device list                           
A1234B5678C9
Product         nRF Sniffer for Bluetooth LE
Ports           /dev/ttyACM0
Traits          nordicUsb, serialPorts, usb

Supported devices found: 1

Instalación de la herramienta de captura nRF Sniffer en Wireshark

A continuación instalaremos Wireshark si no se encuentra instalado en el sistema. La herramienta de captura se instala como un complemento de captura externa en Wireshark. La instalación del complemento se realiza simplemente mediante el sub-comando ble-sniffer bootstrap.

$ ./nrfutil ble-sniffer bootstrap                    
Bootstrapping ble-sniffer...
Bootstrap succeeded

Iniciaremos Wireshark y encontraremos que la opción del menú View > Interface Toolbars > nRF Sniffer for Bluetooth LE existe, la activamos para desplegar la barra de configuración. En el listado de interfaces encontraremos algo similar a nRF Sniffer for Bluetooth LE: /dev/ttyACM0-4.4.

Configuración y captura del tráfico en Wireshark

Tras desplegar la barra de configuración tenemos varias opciones: Interface, Device, Key, Value y Adv Hop. Al iniciar la captura, la herramienta comenzará a mostrar todos los paquetes BLE que detecte dentro del rango, incluyendo publicidad, establecimiento de conexión, paquetes de control de enlace, tráfico L2CAP y comunicación ATT/GATT. En muchos casos será necesario seguir la conexión entre central y periférico, lo cual puede hacerse seleccionando la dirección MAC del dispositivo que se desea monitorizar. Dependiendo del nivel de seguridad del enlace, el tráfico podrá verse en claro o permanecer cifrado.

Primer escenario: tráfico sin emparejamiento (sin cifrar)

Muchos dispositivos BLE operan sin ningún tipo de emparejamiento. Este tipo de funcionamiento es habitual en balizas publicitarias, sensores desprotegidos o periféricos que solo envían telemetría. En estas situaciones, el tráfico no está protegido por ningún mecanismo criptográfico y todos los paquetes se muestran en claro. El análisis es directo: es posible observar las notificaciones ATT, los valores transmitidos, los handles utilizados y en general la estructura completa del intercambio GATT sin necesidad de realizar ninguna operación adicional.

Podemos escanear los dispositivos disponibles desde un dispositivo Android de una forma visual utilizando la aplicación nRF Connect. Si los dispositivos siguen las especificaciones estándar de Bluetooth en cuanto a envío de datos de sensores podemos utilizar la aplicación nRF Toolbox para conectarnos al dispositivo y obtener los datos del sensor.

Los mensajes de advertisement constituyen el primer punto de contacto entre un dispositivo BLE y su entorno. Antes de que exista cualquier conexión, un periférico BLE transmite periódicamente pequeños paquetes de difusión en los llamados advertising channels. Estos paquetes permiten anunciar su presencia, informar sobre sus capacidades, ofrecer datos básicos como identificadores de servicio, nombre del dispositivo o información de fabricante e incluso transmitir telemetría ligera sin necesidad de establecer un enlace.

Realizaremos esta prueba con un pulsómetro. Mientras se encuentra activo el escaneo, los nuevos dispositivos descubiertos mediante los mensajes de advertisement serán añadidos a la opción Device. Si no se ha añadido la dirección MAC a esta lista podemos añadirla mediante el siguiente procedimiento: seleccionar en Key la opción Add LE Address y en el campo Value introducir la dirección MAC, para posteriormente pulsar el botón de la derecha. Seleccionamos el dispositivo y observamos como la cadencia de mensajes se reduce al capturar únicamente mensajes de ese dispositivo. Observamos el mensaje de advertisement del dispositivo. Efectivamente confirmamos de que se trata de un Heart Rate Sensor, de tipo Heart Rate Belt. Procedemos con la conexión con el dispositivo utilizando nRF Toolbox. La conexión se realiza en uno de los canales de advertisement (37, 38 o 39). La herramienta no puede escanear los tres a la vez, por lo que si la conexión se realiza en una canal diferente al que esta siendo escaneado, no se podrá seguir la conexión, ya que se realiza mediante saltos de canales. En ese caso se volverá a iniciar la conexión hacia el dispositivo. El establecimiento de una conexión BLE comienza cuando un dispositivo central, tras recibir un paquete de advertisement de un periférico, decide iniciar un enlace. Para hacerlo, envía un paquete especial denominado CONNECT_IND. Este mensaje marca la transición entre la fase abierta de difusión y el inicio de una relación punto a punto. En el CONNECT_IND se especifican parámetros fundamentales como el intervalo, la latencia o el supervision timeout, así como los canales que se utilizarán para la comunicación. Inmediatamente después del establecimiento de la conexión, ambos dispositivos intercambian cierta información relacionada con sus capacidades a nivel de Link Layer. Uno de los primeros mensajes visibles en una captura suele ser el LL_FEATURE_REQ y su correspondiente LL_FEATURE_RSP. Esta negociación permite a cada extremo comunicar qué funcionalidades soporta, como el uso de Data Length Extension, LE 2M PHY, LE Coded PHY o cifrado. En este caso, en la respuesta, detectamos que el dispositivo soportaría cifrado. Mediante LL_VERSION_IND central y periférico declaran sus versiones de Bluetooth, su número de revisión y, en algunos casos, información del fabricante. Esto facilita la compatibilidad entre dispositivos que podrían implementar variantes del estándar o capacidades específicas. En este caso observamos en el mensaje enviado por el periférico que dispone de la versión 4.0 de Bluetooth, utilizando un chip del fabricante Nordic. Una vez completada la fase inicial de negociación en el nivel de enlace, comienza el proceso habitual de descubrimiento en la capa superior, que se realiza mediante el protocolo ATT (Attribute Protocol). Este descubrimiento permite que la central identifique los servicios y características que ofrece el periférico. Lo normal es que la central envíe una petición como Read By Group Type Request buscando servicios primarios. El periférico responde con los identificadores de los servicios que contiene, junto con los rangos de handles asociados. A partir de ahí, la central continúa realizando solicitudes ATT para enumerar características, descriptores y propiedades, construyendo progresivamente un mapa completo del GATT del dispositivo. Observamos una respuesta a una petición de lectura de un valor Read Response, en este caso de la batería del dispositivo, cuyo valor es el 100%. Existe una escritura (Write Request) por parte del dispositivo central en el que solicita al periférico por los valores del sensor, en este caso de los valores de la frecuencia cardiaca. En este caso el periférico va enviando los valores por su cuenta al tenerlos disponible mediante notificaciones Notification. Más adelante mediante un mensaje Handle Value Notification, el dispositivo envía los valores correspondientes a la frecuencia cardiaca y a los intervalos RR, que sirven para calcular la variabilidad de la frecuencia cardiaca.

Segundo escenario: Legacy Pairing, cifrado vulnerable

El siguiente nivel de complejidad aparece cuando un dispositivo utiliza emparejamiento clásico (Legacy Pairing), el sistema original de BLE 4.x. Este método se basa en la derivación de claves mediante un Temporary Key (TK) que se genera de diversas maneras: desde un PIN de seis dígitos hasta el valor cero cuando no existe entrada del usuario. Debido a esta debilidad, es posible descifrar el tráfico si se captura el proceso de emparejamiento completo.

Una vez capturados los paquetes correspondientes al intercambio de pairing request y pairing response, herramientas como crackle permiten recuperar la Short Term Key (STK) mediante fuerza bruta sobre el TK y, a partir de ella, obtener la Long Term Key (LTK). Con la clave resultante es posible descifrar un archivo PCAP y visualizar la comunicación GATT como si se tratase de tráfico sin proteger.

Para que esto funcione es fundamental iniciar la captura antes del emparejamiento. Si los dispositivos ya estaban emparejados previamente, será necesario eliminar el emparejamiento en ambos extremos y volver a realizar el proceso mientras se captura. Realizamos el mismo proceso anterior con otro dispositivo, en este caso un monitor de presión arterial, en el cuál se comprueba en el dispositivo móvil que se requiere de emparejamiento y se añade a la lista de dispositivos recordados.

El emparejamiento en Bluetooth Low Energy se gestiona a través del Security Manager Protocol (SMP), que opera sobre la capa ATT/L2CAP y se encarga de establecer claves de cifrado, autenticar los dispositivos y proteger la integridad de la comunicación. El objetivo del SMP es garantizar que dos dispositivos puedan intercambiar datos de forma segura, evitando que un tercero pueda interceptar o modificar la información.

Cuando un dispositivo inicia el emparejamiento, se envían mensajes SMP que contienen parámetros esenciales para definir el tipo de emparejamiento y las capacidades de cada extremo. Entre estos parámetros destacan los flags, que son campos de control que indican, por ejemplo, si el dispositivo soporta cifrado de larga duración, si requiere autenticación mediante entrada de usuario o si permite la generación de claves mediante LE Secure Connections basadas en curvas elípticas. Tras los mensajes que observamos en la sección anterior, vemos que el periférico solicita emparejamiento al dispositivo, sin utilizar Secure Connections, es decir, Legacy Pairing. Más adelante observamos como el dispositivo central solicita el emparejamiento únicamente solicitando el flag MITM. El periférico contesta a la solicitud de emparejamiento únicamente ofreciendo el flag Bonding. A continuación se suceden una serie de mensajes en los que se confirma el emparejamiento, se intercambian las claves de cifrado y se inicia la sesión de cifrado mediante los mensajes LL_ENC y LL_START. Es este caso, y al detectar el tipo de emparejamiento, la herramienta descifra todo el tráfico automáticamente sin necesidad de utilizar herramientas externas como crackle al utilizar un emparejamiento Just Works sin ningún tipo de uso de código PIN. Observamos la clave LTK (Long Term Key), en el mensaje Encryption Information. Observamos los paquetes ATT descifrados del dispositivo central y periférico.

Tercer escenario: LE Secure Connections, cifrado moderno robusto

El escenario más seguro es el que emplea LE Secure Connections, introducido con Bluetooth 4.2. Este sistema usa intercambio de claves basado en curvas elípticas (ECDH con P-256), lo que impide recuperar la clave de sesión incluso si se captura todo el proceso de emparejamiento. El uso de ECDH implica que el secreto compartido nunca se transmite, sino que se genera de manera independiente en cada dispositivo, por lo que no existe información útil que pueda ser sometida a ataques de fuerza bruta.

El proceso de captura será igual que en los dos anteriores escenarios, en este caso realizaremos un emparejamiento a una báscula inteligente. Se ha establecido una conexión de comparación códigos PIN. Observamos ahora como entre los flags del emparejamiento se encuentra el Secure Connections. Mensajes más adelante observamos que los mensajes cifrados no han podido ser descifrados.

Conclusión

El nRF52840 Dongle junto con nRF Sniffer for Bluetooth LE constituye una herramienta excelente para aprender a nivel práctico cómo funciona el protocolo BLE. Permite ver en tiempo real el establecimiento de conexiones, la estructura de los paquetes y el comportamiento del tráfico en distintos escenarios de seguridad. LE Secure Connections demuestra cómo los mecanismos modernos de protección basados en criptografía de curva elíptica impiden la recuperación del tráfico cifrado incluso para un observador equipado con un sniffer.