Cazadores de mitos en la DGT 3.0: análisis técnico, ecosistema, protocolos y ciberseguridad de la señal V16

Author: PEDRO CANDEL aka s4ur0n

Cazadores de mitos de la DGT: la V16 por dentro

Conferencia técnica en un evento de seguridad (probablemente RootedCON o similar). Sin fecha exacta, contexto: recién entrado en vigor el sistema el 1 de enero de 2026.

Idea principal

Un tío (Pedro/Aurón, sin filiación con la DGT ni el gobierno) se ha puesto a desmontar balizas V16, leer documentación técnica oficial, auditar APIs y buscar vulnerabilidades del sistema. La conclusión general es que esto huele a negocio montado con prisas, con bastantes agujeros de seguridad y sin demasiada transparencia real pese al discurso oficial.

Conceptos clave

• La plataforma de movilidad conectada (cMovility30.es / movilidadconectada.dgt.es) la gestiona una UTE de Vodafone, Inspide, Pons y otros. No es exactamente "la DGT".
• Para acceder a la API necesitas un certificado X.509, IP pública y rellenar un formulario en Typeform. Sí, Typeform.
• Hay dos protocolos: Protocolo A (baliza → fabricante) y Protocolo B (fabricante → NAP/DGT). La baliza nunca habla directamente con la DGT.
• Los datos que se envían son básicamente coordenadas GPS + timestamp + ID del dispositivo. Sin matrícula, sin datos personales en el protocolo mínimo.
• Los fabricantes pueden enviar más datos de los obligatorios (temperatura, firmware, etc.) sin que nadie lo controle demasiado.
• La transmisión va en UDP, en texto plano, sin cifrado y sin verificación de integridad (ni HMAC ni CRC). Cualquiera con acceso al APN podría falsear la posición de una baliza.
• Las SIM teóricamente son no extraíbles, pero físicamente... se pueden soldar con un destornillador básico.
• Los informes técnicos de certificación mencionan vulnerabilidades bloqueantes conocidas. Están ahí, en los propios PDFs oficiales.

Desarrollo/contexto

El ponente ha comprado balizas de distintos fabricantes, las ha desmontado y documentado lo que llevan dentro: básicamente un GPS, un módulo de comunicaciones 5G/LTE con chip chino (el Y7080E aparece en casi todas), una pila de 9V y poco más. Los testpoints para reprogramar están al aire. El firmware no está ofuscado de forma seria, y mediante ingeniería inversa + placa de desarrollo ha conseguido entender cómo funciona el sistema sin mayor problema.

Lo más gordo desde el punto de vista de seguridad es que los mensajes UDP no están autenticados ni cifrados. Esto significa que si conoces los parámetros del APN y el ID del dispositivo, puedes mandar coordenadas falsas y hacer aparecer balizas donde quieras en el mapa oficial. Lo demostró (o casi) en directo. Además, la actualización de firmware OTA no está implementada en muchos modelos, así que si mañana hay un bug crítico, no se puede parchear remotamente.

Términos técnicos

• NAP: Nodo de Acceso Nacional, el punto centralizado donde llegan todos los datos de las balizas.
• DATEX 2: formato XML estándar europeo para compartir datos de tráfico entre organismos.
• APN: red privada del operador por donde viajan los datos de la baliza, aislada de internet.
• OTA: actualización de firmware de forma remota (Over The Air).
• UDP: protocolo de red sin confirmación de entrega ni cifrado por defecto.

Conclusiones

El sistema V16 es técnicamente funcional pero tiene problemas serios de diseño en seguridad. Los datos que llegan a la DGT son básicamente públicos y nadie te manda una grúa ni una ambulancia cuando activas la baliza, por ahora. El ecosistema huele a negocio rápido montado alrededor de una normativa forzada más que a una solución pensada de verdad. Si el sistema no mejora en integridad y autenticación, la fiabilidad del mapa oficial es cuestionable.

Para investigar más

• Investigación de Darío Estévez sobre señales 5G (mencionada en la charla)
• Especificación DATEX 2 y los conjuntos de datos abiertos de la DGT
• Resolución de 2021 sobre protocolos y formatos de envío de datos (BOE)