La cuenta atrás para 2026 ha convertido a las balizas V16 conectadas en un producto casi omnipresente en gasolineras, tiendas de accesorios y comercios online. A partir de ese año, estos dispositivos sustituirán a los triángulos de emergencia en las carreteras españolas y se convertirán en el único sistema válido para señalizar una avería o accidente desde el propio vehículo.
Sobre el papel, todo encaja con el discurso de una movilidad más segura y conectada. Pero una investigación reciente sobre uno de los modelos más vendidos, la baliza Help Flash IoT, ha abierto un frente inesperado: el de la ciberseguridad de un dispositivo que será obligatorio por ley y que está enlazado con la infraestructura de tráfico de todo el país.
El informe, elaborado por el investigador de seguridad Luis Miranda Acebedo, no cuestiona la utilidad del concepto de baliza conectada, pero sí la forma en la que, en este caso concreto, se ha implementado la seguridad. El análisis describe una combinación de comunicaciones sin cifrado, mecanismos de autenticación débiles y un sistema de actualización remota fácilmente explotable. Todo ello en un producto que, según cifras difundidas por la propia operadora que lo comercializa, habría superado las 250.000 unidades vendidas en España.
Un dispositivo pequeño, una gran responsabilidad
Las balizas V16 conectadas nacen para reducir riesgos en carretera. Su funcionamiento básico es sencillo: el conductor no necesita caminar por el arcén para colocar los triángulos; basta con sacar la baliza por la ventana, fijarla en el techo del vehículo y activar la luz. El dispositivo emite destellos visibles a larga distancia y, además, envía su ubicación a través de la red móvil a un servidor del fabricante, que a su vez comunica la incidencia a la plataforma de tráfico correspondiente.
De esta forma, una avería o accidente deja de ser solo “lo que pasa en la cuneta” para convertirse en un dato en tiempo real que puede aparecer en paneles informativos, navegadores o aplicaciones de mapas. La idea, vista desde la distancia, es lógica: menos exposición para los conductores, más información para el resto.
Precisamente por esa doble naturaleza —dispositivo físico de seguridad y equipo conectado que forma parte de una infraestructura crítica—, la robustez de su diseño de ciberseguridad no es un detalle menor, sino un requisito esencial.
La investigación: desmontar la baliza para ver cómo piensa
La investigación de Luis Miranda se centra en el modelo Help Flash IoT, una baliza conectada que incorpora un módem NB-IoT, una eSIM y un sistema de geolocalización. El trabajo se ha realizado sobre varias unidades adquiridas en el mercado, sin acceder a sistemas de terceros y siguiendo un proceso de divulgación responsable.
El investigador abre el dispositivo, examina la electrónica, accede al puerto serie de depuración y observa tanto los comandos internos del módem como el tráfico que genera cuando se conecta a la red. A partir de ese trabajo, reconstruye el flujo completo:
- El usuario enciende la baliza.
- El dispositivo busca coordenadas GPS.
- El módem NB-IoT se registra en la red del operador.
- La baliza envía periódicamente mensajes a un servidor del fabricante con fecha, posición, identificadores y parámetros de red.
- Desde ahí, la información se reenvía a la plataforma de tráfico correspondiente.
Hasta aquí, nada que no encaje con el diseño esperado. El problema no está en el esquema general, sino en los detalles de cómo se protegen —o no se protegen— esos mensajes.
Primera brecha: comunicaciones en claro y autenticación débil
El informe detalla que los datos enviados por la baliza viajan en texto claro a nivel de aplicación. Es decir, la información que incluye coordenadas GPS, identificadores del dispositivo, hora de activación y otros parámetros no va cifrada con un protocolo estándar tipo TLS o similar.
Eso implica que, si alguien consigue situarse en un punto donde pueda ver ese tráfico, puede leerlo tal cual. No se trata solo de saber que ha habido una incidencia, sino de conocer con precisión dónde, cuándo y con qué dispositivo se ha producido.
A la falta de cifrado se suma otro aspecto: la autenticación. El servidor que recibe los mensajes debe tener forma de comprobar que ese dato procede realmente de una baliza legítima y que no ha sido alterado. El análisis revela que no existen mecanismos sólidos de integridad ni de autenticación mutua que amarren el mensaje de extremo a extremo.
En la práctica, esto abre tres líneas de riesgo:
- Rastreo de ubicaciones. En un contexto controlado —por ejemplo, con acceso al mismo entorno de red— un tercero podría reconstruir patrones de activación y movimientos.
- Suplantación de dispositivos. Si el servidor confía únicamente en un identificador enviado en claro, resulta más sencillo crear mensajes falsos que aparenten proceder de una baliza concreta.
- Manipulación de datos. Sin firmas ni comprobaciones de integridad, un atacante situado “en medio” puede modificar coordenadas o parámetros antes de reenviarlos.
El operador de red puede argumentar que todo esto se produce dentro de un APN privado, un entorno aislado del tráfico de Internet convencional. Pero el informe recuerda que los parámetros de conexión al APN están accesibles desde el propio dispositivo y que, una vez alguien consigue entrar en esa red, la supuesta “muralla” se convierte en una simple valla.
Estaciones base falsas: capturar balizas desde una furgoneta
Más allá de la teoría, la investigación describe un vector de ataque que hace tiempo dejó de ser ciencia ficción: el uso de estaciones base falsas, conocidas como fake eNodeB.
Con una radio definida por software, un ordenador con Linux y herramientas de código abierto, es posible levantar una antena LTE falsa que se anuncia como la mejor opción disponible en una zona concreta. Si, además, se realiza interferencia (jamming) selectiva sobre las frecuencias legítimas, dispositivos como la baliza tenderán a conectarse a esa antena impostora.
En ese escenario, el atacante puede:
- Recibir todos los paquetes que envían las balizas dentro de su radio de alcance.
- Dejar que esos datos “caigan en saco roto”, provocando una denegación de servicio en la práctica.
- O, en un nivel más sofisticado, retransmitir el tráfico hacia la red original tras haberlo leído o modificado.
El cifrado de la capa radio de LTE no impide este tipo de ataques cuando el contenido del mensaje de aplicación viaja en claro y el dispositivo confía ciegamente en cualquier antena que parezca legítima.
Segunda brecha: el modo de actualización OTA, la puerta trasera perfecta
Si la parte de comunicaciones ya es preocupante, el verdadero giro de la investigación llega con el análisis de las actualizaciones OTA (Over-The-Air) de la baliza.
El dispositivo incorpora un modo de actualización vía WiFi que no aparece documentado para el usuario. Para activarlo, basta con mantener pulsado el botón de encendido aproximadamente 8 segundos. No hay PIN, ni confirmación en una aplicación móvil, ni ningún tipo de autenticación adicional: solo el botón.
Una vez en ese modo, la baliza busca una red WiFi con un nombre (SSID) concreto y una contraseña que, según las pruebas realizadas, es la misma en varias unidades distintas. Es decir, credenciales comunes embebidas en el firmware para un gran número de dispositivos.
Cuando el dispositivo se conecta a esa red:
- Consulta por DNS la dirección del servidor de actualizaciones.
- Descarga un archivo JSON de configuración.
- Y, si procede, descarga e instala un nuevo firmware.
Todo ello se realiza sobre HTTP, no sobre HTTPS, y sin verificación criptográfica alguna sobre la procedencia o la integridad del firmware.
Con este diseño, construir un escenario de ataque es relativamente sencillo:
- Un atacante crea un punto de acceso WiFi con el mismo SSID y contraseña que la red de actualización esperada por la baliza.
- Levanta un servidor DNS que responde con su propia dirección IP cuando se consulta el dominio del servidor de actualizaciones.
- Monta un servidor HTTP en el puerto adecuado, con un archivo de configuración y un firmware modificados.
- Cuando alguien activa el modo OTA de la baliza, esta se conecta al punto de acceso falso, resuelve el dominio malicioso y descarga el firmware adulterado.
La prueba de concepto desarrollada por el investigador demuestra que, en condiciones controladas, todo este proceso puede completarse en unos 30-60 segundos desde que se mantiene pulsado el botón.
El resultado es un dispositivo aparentemente intacto, sin signos físicos de manipulación, pero bajo el control de un firmware que ya no responde al diseño original del fabricante.
De “acceso físico” momentáneo a un compromiso persistente
El debate más delicado surge precisamente aquí. Inicialmente, el informe fue trasladado al organismo nacional de ciberseguridad, que consideró que muchas de las vulnerabilidades se basaban en la necesidad de “acceso físico” al dispositivo y, por tanto, no encajaban en determinados criterios de clasificación.
Sin embargo, el modo OTA cambia el significado práctico de ese “acceso físico”. No se trata de desarmar la electrónica, sino de pulsar un botón durante unos segundos. A partir de ahí, el control pasa al firmware malicioso, que puede explotar las debilidades de las comunicaciones móviles sin necesidad de volver a tocar la baliza.
El informe plantea escenarios muy concretos:
- Talleres y servicios de mantenimiento. Un empleado con mala intención podría comprometer la baliza mientras el vehículo está en revisión.
- Puntos de acceso preparados en gasolineras o áreas de servicio. Cualquier baliza puesta en modo OTA en esas zonas podría ser reprogramada de forma transparente para el usuario.
- Ataques móviles. Una furgoneta equipada con el hardware necesario podría recorrer zonas de tráfico denso comprometiendo balizas o interceptando sus comunicaciones en un radio amplio.
En todos los casos, el usuario seguiría viendo una luz que se enciende y parpadea. Lo que ocurre “por dentro” sería mucho más difícil de percibir.
Un síntoma de un problema mayor en el Internet de las Cosas
El caso de la Help Flash IoT no es solo una historia sobre una baliza concreta. Es también un síntoma de un problema más amplio: la rapidez con la que se están desplegando dispositivos conectados en ámbitos críticos —carreteras, hogares, hospitales, industria— sin que, en muchos casos, la seguridad informática se integre desde el diseño inicial.
En este caso concreto, la lista de decisiones cuestionables que recoge la investigación es elocuente:
- Comunicaciones sin cifrado a nivel de aplicación.
- Ausencia de autenticación fuerte entre dispositivo y servidor.
- Falta de mecanismos de integridad en los mensajes.
- Credenciales WiFi hardcodeadas y compartidas.
- Uso de HTTP en lugar de HTTPS para actualizaciones.
- Firmware sin firma digital y sin arranque seguro.
- Modo OTA activable solo con un botón, sin control adicional.
Aplicado a una bombilla o a un enchufe inteligente, todo esto ya sería preocupante. Aplicado a un dispositivo obligatorio, homologado y conectado a una plataforma nacional de gestión de tráfico, el nivel de riesgo potencial es claramente mayor.
Y ahora, ¿qué?
La situación deja varias preguntas abiertas. Entre ellas:
- Si la normativa que regula estos dispositivos tiene en cuenta de forma suficiente la ciberseguridad.
- Si los procesos de homologación incluyen auditorías técnicas profundas o se centran principalmente en aspectos físicos y de conectividad básica.
- Y cómo deberían reaccionar fabricantes y administraciones ante investigaciones como ésta.
Mientras llegan respuestas oficiales, los conductores se encuentran en una posición incómoda: por un lado, se les exige adquirir una baliza conectada para cumplir la ley y mejorar su seguridad; por otro, empiezan a conocer que algunos modelos pueden arrastrar fallos de diseño que no se ven a simple vista.
En todo caso, desmontar el sistema o renunciar a la conectividad no parece una solución razonable. La lección que deja este caso es otra: si la seguridad vial quiere apoyarse en el Internet de las Cosas, la ciberseguridad no puede seguir tratándose como un complemento opcional.
Preguntas frecuentes sobre balizas V16 conectadas y seguridad
¿Qué es exactamente una baliza V16 conectada y en qué se diferencia de la tradicional?
La baliza V16 conectada es un dispositivo luminoso de emergencia que se coloca en el techo del vehículo cuando hay una avería o accidente. A diferencia de las balizas tradicionales, además de emitir destellos visibles a larga distancia, integra un módulo de comunicaciones y geolocalización que envía automáticamente la ubicación del vehículo a una plataforma de tráfico para que otros conductores y los paneles informativos puedan recibir avisos en tiempo casi real.
¿Qué riesgos de ciberseguridad se han detectado en el modelo Help Flash IoT?
La investigación describe dos grandes bloques de riesgos. Por un lado, comunicaciones con el servidor del fabricante sin cifrado ni mecanismos robustos de autenticación e integridad, lo que podría facilitar interceptación, suplantación o manipulación de datos en determinados escenarios técnicos. Por otro, un sistema de actualización OTA vía WiFi que se activa manteniendo pulsado un botón, utiliza una red con credenciales comunes y descarga firmware sin verificar origen ni integridad, lo que permitiría instalar software malicioso en la baliza.
¿Qué puede hacer un conductor que ya tiene una baliza V16 conectada?
Para un usuario de a pie, lo más prudente es evitar manipular el dispositivo, comprobar que está homologado oficialmente y permanecer atento a cualquier comunicación del fabricante o de las autoridades sobre actualizaciones de seguridad o sustituciones. No se recomienda abrir la baliza, modificarla o desactivar su conectividad, ya que eso podría invalidar la homologación y dejar de cumplir los requisitos legales, además de empeorar la protección en carretera.
¿Qué cambios harían falta para que las balizas V16 conectadas sean más seguras?
Los expertos señalan varias mejoras clave: cifrar las comunicaciones de extremo a extremo, implantar autenticación fuerte entre baliza y servidor, añadir mecanismos de integridad en los mensajes, utilizar HTTPS para cualquier actualización remota, firmar digitalmente el firmware y activar el arranque seguro para impedir que se cargue software no autorizado. También consideran esencial que estos requisitos se incorporen a la normativa y a los procesos de homologación, de forma que ningún dispositivo conectado crítico llegue al mercado sin un nivel mínimo de ciberseguridad.
