El punto ciego de los coches conectados: cuando tu rostro se convierte en una vulnerabilidad

Sergio Álvarez, corresponsal de HackerCar, me llamaba hace unos días para ver si me podía trasladar algunas preguntas, con el fin de incluir mi punto de vista en un reportaje que ha acabado publicando el medio sobre el funcionamiento, y sobre todo los riesgos, de los sistemas de reconocimiento de fatiga que están implementando cada vez más marcas de automóviles.

Por supuesto, y como viene siendo habitual en estos casos, le respondí, y dejo, ya una vez publicado el reportaje por parte del medio, mis respuestas y el enlace al mismo a continuación:

¿Cuáles son las principales vulnerabilidades del sistema de detección de fatiga mediante reconocimiento facial de un vehículo conectado?

Los sistemas de detección de fatiga basados en reconocimiento facial arrastran los mismos problemas estructurales que cualquier sistema biométrico, agravados por el entorno conectado del vehículo. Un estudio reciente de threat analysis sobre Driver Monitoring Systems (DMS), siguiendo el estándar ISO/SAE 21434, identificó 115 amenazas potenciales, de las cuales 4 fueron catalogadas como de alto riesgo, concentradas sobre todo en la transmisión de datos, la fiabilidad de los sensores y los protocolos de comunicación.

Entre las vulnerabilidades más críticas esperables en este tipo de sistemas, destacaría:

• Spoofing facial: uso de fotos, máscaras o deepfakes para engañar la cámara y simular un estado de alerta que no es real.
• Interceptación en tránsito: los flujos de vídeo o metadatos biométricos pueden capturarse si viajan sin cifrado robusto entre la cámara, la ECU y la nube.
• Manipulación del propio sensor: ataques físicos o de firmware sobre la cámara que alteran las lecturas antes incluso de que lleguen al algoritmo.
• Debilidad en la autenticación entre módulos: si la comunicación interna del vehículo no exige credenciales fuertes, un atacante que ya esté dentro de la red del coche puede inyectar datos falsos.

Ya hablé de este dilema de fondo (seguridad frente a privacidad) cuando analicé la llegada del reconocimiento facial a plataformas masivas, un debate que aplica igual de bien al automóvil conectado, por si lo quieres revisar.

¿De los tres sistemas para la detección de fatiga del conductor que se explican en el artículo que te adjunto, ¿cuál te parece el más seguro frente a los black hackers intrusos y por qué? 

De los tres modelos que compara el artículo de Sensors (multisensor, basado en smartphone y basado en cloud) me quedo con el multisensor como el más resistente frente a intrusos, aunque no sea el más barato ni el más cómodo.

La razón es sencilla: combina señales fisiológicas (EEG, ECG, EOG) con datos del vehículo (ángulo del volante, presión de frenado), lo que obliga al atacante a falsear varias fuentes simultáneas y coherentes entre sí para engañar al sistema, algo mucho más complejo que suplantar una sola cámara o un solo sensor de móvil.

Pero si me preguntas por los tres, te digo:

• Multisensor: mayor coste y complejidad de implementación, pero la redundancia de señales dificulta enormemente la falsificación coordinada.
• Smartphone: cómodo y barato, pero depende de un dispositivo personal con su propio ecosistema de vulnerabilidades (apps maliciosas, jailbreak, redes wifi abiertas).
• Cloud: centraliza el procesado y facilita el análisis, pero traslada el riesgo a la superficie de ataque de la conexión y del propio proveedor cloud, con la latencia y el punto único de fallo que eso implica.

¿Cómo se deberían proteger las imágenes registradas por la cámara desde que esta las capta hasta que son analizadas y/o almacenadas -en el caso de gestión de flotas-?

En un entorno de flotas, donde el volumen de datos biométricos que circula es mucho mayor, la protección debe aplicarse en cada eslabón de la cadena, no solo al final del proceso.

El propio TARA de DMS recomienda reforzar cifrado, autenticación estricta y control de accesos como pilares básicos para este tipo de sistemas.

En la práctica, para que nos entendamos, esto se traduce en:

• Cifrado en el propio sensor: la imagen debería cifrarse en el momento de la captura, antes de salir del módulo de la cámara.
• Cifrado en tránsito: todo el trayecto entre la cámara, la ECU y, si aplica, el servidor de la flota, debe ir bajo TLS o protocolos equivalentes robustos.
• Procesado en el edge cuando sea posible: analizar los rasgos de fatiga localmente y enviar solo el resultado (alerta/no alerta), no el vídeo completo, reduce drásticamente la superficie de exposición.
• Cifrado en reposo con gestión de claves separada: si se almacena, la clave de descifrado no debería vivir en el mismo sistema que los datos.
• Minimización y borrado automático: conservar solo lo estrictamente necesario y durante el tiempo mínimo legal, algo que ya comenté al hablar del vehículo como dispositivo de identidad digital y de todo lo que eso implica en términos de trazabilidad.
• Autenticación fuerte para el acceso administrativo, ya que en flotas suele haber varios perfiles (gestores, mantenimiento, seguros) con acceso potencial a esos datos.

¿Consideras que los sistemas de despersonalización de los conjuntos de datos en su estado actual -por ejemplo, guardar las plantillas biométricas por separado de los datos personales- son suficientes para almacenar los datos biométricos con seguridad? ¿O aún así existen fallas?

La separación entre plantillas biométricas y datos personales (guardar por un lado el «hash» facial y por otro el nombre del conductor) es un avance real, pero no es una solución definitiva.

Ya lo analicé al hablar del principio de des-identificación: aunque el hash no sea directamente vinculable a la identidad, sigue existiendo el riesgo de reidentificación si se cruza con otras bases de datos o metadatos del propio vehículo (matrícula, geolocalización, horarios).

¿Qué podemos hacer?

Pues se me ocurren tres acercamientos:

• Reidentificación por correlación: combinar la plantilla con otros datos del coche puede acabar apuntando a una persona concreta sin necesidad de romper el cifrado.
• Ciclo de vida del dato biométrico: a diferencia de una contraseña, un rostro no se puede «cambiar» si se filtra, lo que convierte cualquier brecha en un problema permanente, algo que ya defendí cuando insistí en tratar la biometría como un login y no como una contraseña.
• Calidad de la anonimización: no todos los sistemas aplican técnicas robustas (k-anonimato, differential privacy); muchos se quedan en una simple separación de tablas, insuficiente frente a un atacante con recursos.

Al comprarte un coche, ¿qué le exigirías a un fabricante para estar tranquilo con los riesgos que pueda tener la identificación biométrica de tu rostro?

Como comprador, y desde mi experiencia analizando riesgos digitales, exigiría un conjunto claro de garantías antes de aceptar que mi rostro forme parte del sistema del vehículo.

A saber:

• Procesado local por defecto: que el reconocimiento facial se ejecute en el propio coche, sin enviar el vídeo en bruto a servidores externos salvo consentimiento explícito.
• Certificación bajo UNECE R155/R156, que exige gestión del ciclo de vida completo de la ciberseguridad del vehículo, no solo en el momento de la venta.
• Transparencia total sobre qué datos se capturan, dónde se almacenan y durante cuánto tiempo.
• Posibilidad real de borrado y portabilidad de mis datos biométricos si cambio de vehículo o de fabricante.
• Auditorías de seguridad independientes periódicas, no solo autoevaluaciones internas del fabricante.
• Hardware root of trust: que la clave criptográfica que protege los datos biométricos esté anclada en un chip seguro y no dependa únicamente de parches por software.

¿Cómo protegen las normas UNECE/R155 Y UNECE/R156 de las amenazas a los sistemas de detección de fatiga?

El reglamento UNECE R155 obliga a los fabricantes a implantar un Cyber Security Management System (CSMS) que cubra todo el ciclo de vida del vehículo (desarrollo, producción y postventa), incluyendo identificación exhaustiva de amenazas, evaluación continua del riesgo y monitorización de incidentes.

Esto afecta directamente a los sistemas de detección de fatiga, ya que cualquier vulnerabilidad detectada en la cámara o en el procesado de datos biométricos debe reportarse y mitigarse de forma proactiva, no solo en el lanzamiento del modelo.

El R156, complementario, regula la gestión de las actualizaciones de software (incluidas las OTA), asegurando que los parches que corrigen fallos en el sistema de monitorización del conductor se validen y desplieguen de forma segura y trazable.

Es decir:

• R155: exige gestión de riesgos continua, no una foto fija en el momento de la homologación.
• R156: garantiza que las actualizaciones que corrigen vulnerabilidades del DMS lleguen de forma íntegra y autenticada.
• Punto débil compartido: ambos reglamentos dependen en parte de la buena praxis del fabricante en la implementación, por lo que un enfoque solo software, sin seguridad anclada en hardware, sigue dejando huecos a largo plazo, tal y como advierte el propio análisis técnico sobre estas normas.

Dejo, para terminar, el enlace al reportaje de HackerCar donde se me menciona.