Una pequeña explicación del uso de BLE (Bluetooth Low Energy) en Radar COVID-19

Hoy en día, tanto el protocolo Bluetooth como la especificación Bluetooth Low Energy (BLE) se han convertido en unos de los protocolos más utilizados en el mundo. De hecho, muchos de los dispositivos más cotidianos y que usamos en el día a día lo tienen incorporado: ordenador personal y navegadores de Internet - que se pueden usar para proteger la navegación en canales paralelos como en el caso del Second Web Browsing (2FWB) - e incluso en páginas web con la especificación WebBlueTooth, smartphones, tablets, smartwatches, auriculares como los AirPods Pro, teclados, luces inteligentes, impresoras, trackers busca-cosas, cámaras digitales con accesos BLE,  altavoces como los del ataque Diritytooth, smartTVs, patinetes eléctricos, vídeoconsolas y muchos, muchos más.

Figura 1: Una pequeña explicación del uso de
BLE (Bluetooth Low Energy) en Radar COVID-19

Todos ellos tienen características de seguridad y privacidad que hay que analizar, y en el mundo del Ethical Hacking y la auditoría de seguridad tenemos herramientas como BLECTF para probar nuestras habilidades en competiciones Capture The Flag basadas en BLE o retos en formaciones de pentesting BLE, herramientas como BTLEJack & Micro:Bit para probar los ataques Man in the Middle que se pueden programar con Microsoft MakeCode, como vimos,  y la herramienta HomePWN del equipo de Ideas Locas de CDCO que construyó Pablo González y sus compañeros, que fue a la BlackHat Europe el año pasado para explicar cómo se pueden hacer ataques a conexiones BLE. 

Al final, Bluetooth es un protocolo de comunicación inalámbrica que actúa con una radiofrecuencia en la banda ISM de los 2.4 GHz que puede ser usado para muchas cosas. Permite la transmisión de datos de forma inalámbrica entre distintos dispositivos, permitiendo, por ejemplo, comunicar nuestro portátil u ordenador con periféricos como un teclado y un ratón o que nuestro smartphone se comunique con nuestros auriculares inalámbricos. También, se utiliza para la compartición de archivos entre dispositivos, como por ejemplo música o fotografías. Además, Bluetooth no necesita estar en la línea de visión de los dispositivos, es decir, puede haber obstáculos o una pared entre ellos.

En posts anteriores, ya se ha hablado bastante de este protocolo, analizando ciertos aspectos de éste y mostrando algunas herramientas para poder estudiarlo, analizarlo - como ya hemos dicho - y ver posibles ejemplos de ataques. En este artículo, quiero centrarme en explicar cómo se puede utilizar Bluetooth o cómo se está utilizando para combatir al COVID-19. Para ello, me centraré en una pequeña parte, pero muy importante, de este protocolo: el Bluetooth advertising.

Bluetooth advertising

¿A qué nos referimos cuando hablamos de Bluetooth advertising? Bluetooth advertising es la forma en la que un dispositivo Bluetooth se da a conocer de forma pública para que otros dispositivos puedan conectarse a él. Para realizar las comunicaciones, Bluetooth Low Energy (BLE) dispone de 40 canales, numerados del 0 al 39 en la banda de los 2.4 GHz, tal y como puede verse en la imagen siguiente. Generalmente, durante la publicación o el advertisement, se utilizan los canales 37, 38 y 39, aunque en versiones recientes de Bluetooth también pueden utilizarse otros canales. Nosotros solamente nos centraremos en el uso de estos 3 canales. La parte buena de estos 3 canales, tal y como se muestra en la imagen siguiente, es que no colisionan con ningún canal WiFi.

Figura 2: Canales utilizados en Bluetooth Low Energy (BLE) 

Es importante destacar también que, en este artículo, no entraremos en todos los detalles de cómo se realiza el proceso de advertisement. Solamente, quiero dar una buena intuición de cómo funciona y qué es lo que se hace durante este proceso para explicar posteriormente cómo se está utilizando para el COVID-19.

Durante el proceso de anuncio o advertisement, el dispositivo BLE transmite el mismo paquete en los 3 canales. De esta forma, otro dispositivo u otros dispositivos BLE serán capaces de ver esos paquetes y obtener una determinada información. Es importante mencionar que no todos los dispositivos BLE envían paquetes de anuncio. Esto depende del tipo de aplicación para la que está pensado y de su rol GAP (Generic Access Profile), definido en una de las capas más superficiales que forman la arquitectura de BLE.

Roles GAP (Generic Access Profile)

Antes de ver los roles GAP que existen, es importante mencionar que se distinguen dos tipos de aplicaciones en función de estos roles: aplicaciones orientadas al broadcasting y aplicaciones orientadas a la conexión. En la primera de ellas, el dispositivo no admite conexiones, solamente envía paquetes de anuncio. En la segunda, los dispositivos BLE establecen una conexión e intercambian datos entre ellos. Existen los siguientes 4 roles GAP:

- Broadcaster: envían cada cierto tiempo paquetes de anuncio, sin admitir conexiones. El tiempo varía entre unos pocos milisegundos y aproximadamente 10 segundos. Es configurable.

- Observer: están atentos a leer y captar esos paquetes de anuncio. Tampoco admiten conexiones.

- Peripheral: son capaces de enviar paquetes de anuncio para darse a conocer y aceptar conexiones procedentes de una central.

- Central: son capaces de leer y captar paquetes de anuncio para establecer una conexión con esos dispositivos. Si se trata de un broadcaster, lógicamente, no podrán establecer una conexión con él. Sin embargo, si se trata de un dispositivo con el rol peripheral sí. Es importante destacar que un mismo dispositivo puede utilizar varios roles al mismo tiempo. Por ejemplo, nuestro smartphone. Este podría actuar como central para un smartwatch o unos auriculares inalámbricos y al mismo tiempo actuar como peripheral para nuestro ordenador. 

Llegado a este punto, muchos os preguntaréis lo siguiente: ¿para qué quiero un dispositivo que sea capaz de darse a conocer o de anunciarse para luego no admitir conexiones? No os preocupéis, más adelante veréis cómo se pueden utilizar para combatir al COVID-19. Hasta este momento, solamente quiero que os quedéis con el siguiente concepto: un dispositivo BLE es capaz de enviar paquetes “públicos” y visibles por otros dispositivos, sin la necesidad de tener que admitir conexiones.

Un paquete de anuncio tiene una capacidad de payload útil de 37 bytes, de los cuáles 6 bytes son utilizados obligatoriamente para especificar un identificador único (que no tiene por qué ser siempre el mismo). Esto nos deja disponibles 31 bytes para enviar información, que generalmente suele enviarse con una determinada estructura e identificadores. En caso de necesitar enviar más información podemos utilizar la funcionalidad Scan Request y Scan Response.

Además, el dispositivo receptor es capaz de medir la fuerza de la señal (RSSI o Received Signal Strength Indicator) con la que está recibiendo esos paquetes de anuncio o advertisement. Esto permite al receptor o descubridor aproximar la distancia a la que se encuentra el emisor. Es cierto que este valor no solamente depende de la distancia, sino que también depende de otros factores como los obstáculos, las paredes y otros factores ambientales. Además, es un valor que varía en función del dispositivo BLE que se esté utilizando.

Aun así, existen varios papers que ya han obtenido resultados bastante buenos combinando este valor con otras métricas. Lo que sí está claro es que podemos usarlo, combinándolo con métodos matemáticos (Kalman Filter por ejemplo) y ya estudiados, para predecir una distancia. Quizás, no podamos predecir distancias directas pero sí que podemos definir “cubos” o distancias orientativas.

BlueTooth Low Energy y su uso frente al COVID-19: Exposure Notifications

Llegados a este punto, ya podemos analizar o ver cómo podemos utilizar Bluetooth o más concretamente BLE para combatir al COVID-19. Gracias al RSSI podemos aproximar distancias entre dispositivos y gracias a los paquetes de anuncio podemos compartir información con otros dispositivos sin necesidad de tener que establecer una conexión previa.

Partiendo de que todos nosotros solemos llevar un smartphone en el bolsillo, podríamos utilizar BLE para medir de forma automática la distancia con todas las personas con las que estamos en contacto en nuestro día a día. Además, gracias a los paquetes de anuncio podríamos guardar un número o identificador de todas esas personas con las que hemos estado en contacto, dentro de un almacenamiento local de nuestro móvil, de forma que si alguna de estas personas se contagia del virus seamos capaces de saberlo y saber cuánto tiempo hemos estado en contacto con ellas y, así, determinar qué probabilidad de contagio tenemos.

Pues, esto ya existe. Las empresas Google y Apple han desarrollado una API, llamada Exposure Notifications, que el gobierno de cada país puede incluir en una aplicación Android o Apple para detectar y rastrear contagios de COVID-19. En el caso de España es Radar COVID. Además, existe ya algún estudio que dice que esta aplicación es bastante más efectiva que los rastreadores manuales, detectando hasta el doble de contagios. 

¿Cuál es el objetivo de Radar COVID?

El objetivo fundamental es ser capaz de detectar contagios sin utilizar datos personales que identifiquen a una persona. Entonces para ello, voy a utilizar el ejemplo el gráfico siguiente, que proporciona Google para dar detalles del algoritmo, ver qué papel juega el BLE en todo esto y mostrar que, efectivamente, no utiliza datos personales del usuario.

Figura 3: Gráfico que explica el funcionamiento

Partimos del ejemplo del gráfico, donde nuestros protagonistas son dos personas que no se conocen entre ellas, Alice y Bob, y que tienen un smartphone con esta aplicación y con el BLE activado. Sus smartphones generan identificadores únicos (Rolling Proximity Identifiers) cada 15 minutos aproximadamente, a partir de una clave que se genera cada 24 horas (Temporary Exposure Key). Estos identificadores son emitidos cada cierto tiempo (unos milisegundos) por el smartphone en forma de paquetes de anuncio BLE. Para más detalles, ver la tabla siguiente.

Figura 4: Estructura e información que envía nuestro smartphone cuando

realiza el anuncio o advertisement utilizando la API Exposure Notifications

Entonces, cuando Alice y Bob se encuentran, sus smartphones son capaces de obtener los identificadores de uno y de otro, es decir, el smartphone de Bob obtiene el identificador de Alice y el de Alice obtiene el identificador de Bob. Estos identificadores se almacenan de forma local en sus smartphones. 

Cuando a Bob le diagnostican y le comunican que está contagiado de COVID-19, este tiene la posibilidad de subir a la nube todos los identificadores únicos que ha generado su smartphone, de forma voluntaria. De esta forma, cuando los identificadores de Bob estén en la nube, la aplicación será capaz de alertar a Alice, comparando los identificadores con los que ha estado en contacto en los últimos 14 días y almacenados en su móvil de forma local con los identificadores que hay en la nube.

La aplicación NO almacena los identificadores de todos los paquetes de anuncio que recibe, solamente almacena aquellos que cumplen con el tiempo de exposición y distancia especificados. Este tiempo y distancia lo decide cada aplicación que utiliza la API. La API genera la Temporary Exposure Key cada 24 horas por cuestiones de privacidad y seguridad. Además, los Rolling Proximity Identifiers se renuevan cada 15 minutos con el fin de evitar que un smartphone pueda ser monitorizado a través de estos identificadores. Seguramente muchos de vosotros tengáis interés por ver más acerca de esta API, así que os dejo por aquí un enlace a la documentación.

Y con esto termina el post 😊. A mí, personalmente, me parecen increíbles muchas de las aplicaciones que se le están dando al BLE. Una de ellas es esta. Y las que vendrán.

Saludos,

Autor: Alberto Rivera, de Ideas Locas CDCO