Un ejemplo de protección de la IA en cabina mediante TEE en un SoC FPGA seguro

Este artículo analiza los entornos de ejecución confiables, que ya se utilizan en una variedad de dispositivos conectados, mostrando cómo el uso de TEE y un FPGA SoC puede funcionar en vehículos cabina AI.

En la Parte I de este artículo, Entornos de ejecución de confianza (TEE) en coches conectados, se analiza que, si bien un Entorno de ejecución de confianza (TEE) se usa ampliamente en teléfonos móviles y otros dispositivos conectados para proteger funciones críticas, la adopción en vehículos conectados es baja. La falta de TEE puede crear vulnerabilidades en el sistema. En la Parte II, tomaremos la IA en cabina como una aplicación de ejemplo y discutiremos cómo un TEE moderno y un SoC FPGA pueden ser su plataforma segura.

Sistema de IA en cabina típico

La IA en la cabina es parte de un sistema avanzado de asistencia al conductor (ADAS) y, de hecho, se implementa más popularmente que la conducción autónoma. La IA en la cabina aprovecha las cámaras u otros sensores para brindar a los conductores y pasajeros una guía de seguridad contextual, o brindar opciones como la voz o los gestos para controlar el vehículo. Por ejemplo, las cámaras orientadas hacia adentro son expertas en monitorear a los conductores de camiones para detectar ebriedad, distracción, somnolencia y fatiga para alertar al conductor y prevenir accidentes. Actualmente se utilizan ampliamente en vehículos comerciales y camiones. La misma tecnología está comenzando a penetrar en los vehículos de consumo para observar el comportamiento relacionado con el conductor por motivos de seguridad. Las cámaras impulsadas por IA también pueden alertar cuando se dejan niños y mascotas en el vehículo para evitar muertes relacionadas con el calor.

Un sistema típico en la cabina monitorea el comportamiento del conductor, verifica si los ocupantes usan cinturones de seguridad y se puede capacitar para rastrear objetos de interés como teléfonos celulares, llaveros, asientos para bebés, etc. El sistema debe cumplir muchas funciones, incluida la cadena de señal de video basada en aprendizaje automático , comunicación con otras ECU como el ADAS central o el sistema de infoentretenimiento, y admite actualizaciones de firmware.

También puede realizar la detección de puntos ciegos:los espejos retrovisores laterales aumentados con cámaras de factor de forma pequeño se pueden usar para ejecutar algoritmos ML para detectar vehículos en el punto ciego del conductor. Además, puede descargar el procesamiento como la autenticación de la red en el vehículo (IVN) del ADAS central.

Un ejemplo de hardware reforzado

PolarFire SoC FPGA de Microchip es un ejemplo de hardware que puede admitir este tipo de funciones consolidadas, sistema de criticidad mixta. Permite aplicaciones de inteligencia artificial en la cabina con inferencias eficientes en la estructura FPGA y el subsistema del microprocesador para ejecutar trabajos de control y monitoreo. Admite RTOS deterministas junto con Linux enriquecido en procesadores RISC-V de cuatro núcleos de alta eficiencia energética (consulte la Figura 1).

Figura 1. Plataforma de IA en cabina PolarFire SoC. La inferencia ML se ejecuta en tejido FPGA. RISC-V SoC aloja funciones de control y supervisión.

Para fortalecer el hardware, PolarFire SoC tiene medidas de seguridad integradas que incluyen soporte a prueba de manipulaciones más contramedidas de análisis de potencia diferencial (DPA). Esto protege el chip contra exploits de canal lateral que tienen como objetivo extraer flujos de bits y, por lo tanto, evita la clonación. Al utilizar la infraestructura de programación segura, un fabricante de automóviles tiene control total sobre la cantidad de FPGA que se pueden programar, protegiendo así contra la sobreconstrucción. PolarFire SoC también admite arranque seguro utilizando una memoria flash de arranque segura de 128 kB habilitada para SECDED.

El modelo de inferencia de IA y otros activos de datos valiosos deben protegerse

En este sistema, los activos de datos valiosos incluyen:

• IVN:el acceso no intencionado al IVN ("bus CAN") puede permitir que un adversario se apodere del vehículo
• Información de identificación personal (PII) del conductor y del pasajero:la PII debe ocultarse para la privacidad del consumidor
• OTA:si el código OTA o los datos están dañados o secuestrados, se puede inyectar firmware malo o malicioso
• Modelo de IA:el modelo de inferencia es susceptible al robo y ataque de IP
• Secretos:las claves y las bibliotecas de cifrado deben estar protegidas para garantizar el algoritmo de firma digital (DSA) de los mensajes IVN

La confidencialidad, integridad y disponibilidad (CIA) de estos activos se deben considerar durante el diseño.

Las superficies de ataque y las amenazas a estos activos incluyen:

Superficies de ataque	Exploits
Capas de red y aplicaciones	Malware, desbordamiento de búfer para explotar IVN, OTA, robar PII
SO enriquecido	Un sistema operativo rico como Linux tiene una gran superficie de ataque. Cualquier firmware que no sea libre también presenta opacidad y riesgos. Los exploits pueden derribar todo el sistema o pueden permitir que un adversario ingrese silenciosamente a través del SO enriquecido para manipular otros activos.
Sensores	"Model Hacking" o "Adversarial Machine Learning" es cuando la memoria del sensor es accesible por aplicaciones que no son de confianza, el malware puede perturbar la memoria del sensor, lo que resulta en un funcionamiento no intencionado de ADAS.
Sensores	“Inversión por modelo sustituto”:cuando un adversario puede controlar la entrada y observar la salida del modelo de inferencia al poder leer y escribir en la memoria, puede recrear el modelo. Podría usar esa copia para conocer las tendencias y distribuciones en los datos de entrenamiento o para planificar futuros ataques.

Un ejemplo de un entorno de ejecución confiable

Un TEE que proporciona seguridad por separación es una excelente contramedida para diseñar un modelo de confianza cero para salvaguardar estos activos de datos.

Un TEE que adopta un nuevo enfoque es MultiZone® Security de Hex Five. Hace uso de primitivas de partición de memoria:PMP de "protección de memoria física" que es estándar en todos los RISC-V o MPU de "unidad de protección de memoria" en Arm®, y niveles de privilegios en la CPU (modo M y modo U para RISC- Niveles V, Handler y Thread para Arm®) para crear múltiples contenedores o zonas seguras.

Una configuración de MultiZone en PolarFire SoC puede parecerse a la Figura 2. Cada cuadro rojo indica un bloque funcional protegido en un "contenedor" o una "zona". Dentro de cada zona, solo el código autorizado y asignado puede acceder a regiones de memoria específicas de acuerdo con los permisos de lectura-escritura-ejecución configurados por un archivo de política MultiZone. Los controladores de interrupciones se asignan a una zona para que solo se ejecute con privilegios de modo de usuario en lugar del modo de kernel, para cumplir con el modelo de confianza cero.

Las cinco zonas son:

1. OTA:protege la CIA del código y los datos OTA
2. Cámara:protege los datos del sensor de la cámara
3. Autenticación de IVN:similar a un HSM, esta zona protege las claves y el cifrado para DSA
4. RTOS:controla el IVN
5. Enclave de Linux:se contendrán las fallas de Linux

Estas zonas se muestran en la Figura 2.

Figura 2. MultiZone crea 5 "zonas" en PolarFire SoC. Solo MultiZone se ejecuta en modo M, que es CPU Ring 0 en RISC-V. Cada cuadro rojo es una zona separada por hardware definida por software .

Esta configuración de ejemplo muestra cómo un TEE y su hardware complementario crean una plataforma segura fundamental para una aplicación de IA en cabina.

TEE es una capa fundamental

Una buena postura de seguridad para vehículos conectados debe incluir como mínimo:

• Seguridad de la aplicación
• Sistema de prevención de detección de intrusiones (IDPS) para la seguridad de la red
• Secure OTA
• Entorno de ejecución confiable
• Hardware con primitivas de seguridad integradas, raíz de confianza

Apoyar los TEE en nuestros vehículos es fundamental, no es diferente de tener TEE en nuestros teléfonos. Ese es un camino para hacer que nuestros automóviles sean más seguros que nuestros teléfonos inteligentes.

Diptesh Nandi, de Microchip, es coautor de este artículo.

Los artículos de la industria son una forma de contenido que permite a los socios de la industria compartir noticias, mensajes y tecnología útiles con los lectores de All About Circuits de una manera que el contenido editorial no es adecuado. Todos los artículos de la industria están sujetos a estrictas pautas editoriales con la intención de ofrecer a los lectores noticias útiles, experiencia técnica o historias. Los puntos de vista y las opiniones expresados ​​en los artículos de la industria son los del socio y no necesariamente los de All About Circuits o sus redactores.