AAOS SDV: Diseño de seguridad integral

En Google, creemos que nuestros productos deben tener un diseño de seguridad integral, por lo que creamos el sistema operativo Android Automotive para vehículos definidos por software (AAOS SDV) en plataformas existentes y probadas en el mercado, aprovechando tecnologías de virtualización como Cuttlefish. Si bien nuestros anuncios de lanzamiento se enfocaron en las funciones, en esta entrada de blog, se describen algunos de los conceptos de seguridad.

Fundamentos: Aislamiento de dominios

Virtualización para aislar instancias alojadas en conjunto

La tendencia actual de consolidar las unidades de control electrónico (ECU) en un solo chip reduce el aislamiento, ya que ejecuta varios dominios en paralelo.

Si bien las instancias de AAOS SDV proporcionan mecanismos de aislamiento internos, a menudo es preferible ejecutar dominios lógicos de forma independiente. Por ejemplo, un clúster y un sistema de infoentretenimiento tienen requisitos distintos. Usamos máquinas virtuales para ejecutar varias instancias en paralelo, lo que garantiza que el uso compartido siga siendo explícito y que el aislamiento sea el comportamiento predeterminado.

Seguridad de Android heredada

AAOS SDV evolucionó a partir de Microdroid, una versión minimalista de Android optimizada para máquinas virtuales de privacidad (pVM). Este linaje proporciona a los ingenieros de la plataforma de Android funciones de seguridad establecidas que ya conocen.

Aislamiento de procesos y denegación predeterminada

AAOS SDV sigue el modelo de aislamiento basado en el ID de usuario (UID) de Android para configurar un entorno de pruebas para cada aplicación. Cada servicio se ejecuta en un proceso dedicado con un UID único para administrar los derechos de acceso, los directorios de datos y otras restricciones. Empleamos capacidades de la interfaz del sistema operativo portátil (POSIX) para limitar estrictamente las operaciones y combinarlas con Security-Enhanced Linux (SELinux) para aplicar una postura de "denegación predeterminada". Este enfoque restringe cada servicio al mínimo absoluto requerido, lo que significa que las configuraciones faltantes bloquean el acceso en lugar de crear un sistema demasiado permisivo. Aplicamos esta misma estrategia a nuestro sistema de permisos de comunicación, como se explica más adelante en este artículo.

Gestión de vulnerabilidades probada

AAOS SDV integra la infraestructura madura de respuesta de seguridad y gestión de vulnerabilidades de Android para identificar, clasificar, solucionar y divulgar los hallazgos de seguridad. Este ciclo de vida incorpora análisis automatizados continuos, pruebas de penetración anuales en profundidad y estadísticas basadas en socios a través del proceso de informes de vulnerabilidades de seguridad de Android. El equipo de seguridad clasifica las vulnerabilidades descubiertas, asigna calificaciones de gravedad según el riesgo y realiza un seguimiento de la solución hasta que se completa. Coordinamos las políticas de divulgación y lanzamiento a través de los Boletines de seguridad de Android mensuales, complementados con rigurosas auditorías de seguridad periódicas y revisiones arquitectónicas integrales para garantizar la resiliencia de la plataforma a largo plazo.

Garantiza una entrega segura de software

Además de garantizar el aislamiento de procesos, una plataforma segura debe garantizar la integridad del código antes de la ejecución. Protegemos la entrega de software a través de los siguientes enfoques:

Entrega de software autenticada

AAOS SDV proporciona dos métodos de instalación. Primero, instalamos el software directamente en particiones de sistema, producto o proveedor de solo lectura, que validan las firmas en cada arranque. Esto protege los componentes básicos del sistema.

En segundo lugar, utilizamos paquetes Android Pony EXpress (APEX) para los servicios. Cada APEX encapsula el software y sus dependencias, y trata el paquete como una partición con validación de firma obligatoria. En AAOS SDV, APEX trata la firma de código como un contrato continuo aplicado por hardware. APEX garantiza que la ejecución de código malicioso se mitigue a través de cuatro pilares principales: 

1. Almacenamiento inmutable

• El mecanismo: El kernel de Android ejecuta el archivo apex_payload.img directamente como un dispositivo de almacenamiento sin procesar con el bucle invertido de solo lectura y lo activa con la marca estricta MS_RDONLY.
• Por qué es más seguro: Esto no expone ninguna ruta de escritura al SO porque los archivos no se descomprimen en el almacenamiento del vehículo. Incluso si un atacante obtiene privilegios de administrador, no puede modificar el código APEX en ejecución porque la capa del sistema de archivos rechaza todos los comandos de escritura.

2. Integridad criptográfica

• El mecanismo: La firma criptográfica valida un árbol de Merkle de toda la imagen del sistema de archivos.
• Por qué es más seguro: El kernel usa dm-verity por bloque para verificar la firma de cada bloque de datos de 4 KB de forma dinámica. Si un atacante modifica un bloque sin procesar en la memoria flash, el kernel detecta la falta de coincidencia del hash y detiene la ejecución de inmediato.

3. Aislamiento estricto

• El mecanismo: Esto aplica las reglas de aislamiento de procesos como se describe en la sección Aislamiento de procesos para crear un entorno de pruebas, con el APEX activado como una partición dedicada en /apex.
• Por qué es más seguro: Cada servicio recibe su propio directorio de usuario y datos, lo que restringe el acceso a menos que el uso compartido sea explícito. Cuando se crea una partición dedicada, Android establece un espacio de nombres de vinculador dedicado, lo que garantiza que solo se pueda acceder a las bibliotecas expuestas de forma explícita desde los daemons del sistema sin privilegios, lo que minimiza la superficie de ataque.

4. Recuperación atómica

• El mecanismo: APEX usa un diseño "Activo/Copia de seguridad" para habilitar reversiones con búfer doble. El APEX flasheado de fábrica permanece en la partición /system inmutable, mientras que las actualizaciones residen en la partición /data mutable.
• Por qué es más seguro: Si una actualización falla o parece maliciosa, el daemon apexd la marca como "failed" durante el inicio anticipado. El sistema intercambia instantáneamente los vínculos simbólicos a la partición /system. Esta recuperación atómica ayuda a garantizar que el sistema no permanezca en un estado dañado.

Resiliencia: Desarrollo seguro para la memoria

La carga verificada protege el sistema de modificaciones externas, pero la resiliencia de la plataforma también depende de cómo se compila el código subyacente. Para los componentes nuevos desarrollados para AAOS SDV, priorizamos la seguridad de la memoria.

Rust como lenguaje principal

AAOS SDV se orienta a sistemas pequeños con requisitos de disponibilidad rápidos. Esto impide la compilación en la pila completa de Android, por lo que limitamos nuestro alcance al framework nativo. Para crear la infraestructura necesaria para un sistema distribuido, desarrollamos varios componentes además de la infraestructura existente y adoptamos Rust como lenguaje principal. También usamos Rust para desarrollar la lógica empresarial de los servicios, lo que ayuda a los socios a escribir software seguro. Por diseño, Rust aprovecha las funciones de seguridad de la memoria para ayudar a prevenir clases comunes de vulnerabilidades de seguridad de la memoria, mientras admite la capacidad de procesamiento del equipo cuando se escribe código nativo.

Confianza distribuida: Red y control de acceso

Los vehículos definidos por software requieren interacciones seguras entre dominios aislados. La arquitectura de aprovisionamiento de malla de AAOS SDV aborda esta complejidad mediante la verificación criptográfica de la versión y el autor de cada extremo de comunicación.

Aprovisionamiento de dispositivos y mallas

La malla de AAOS SDV establece la autenticación vinculando matemáticamente la identidad de red de cada componente a su estado de ejecución binario real. Este modelo reemplaza la confianza implícita del software por la verificación basada en hardware.

La autenticación de malla está diseñada para ser continua y criptográfica. Esto evita situaciones en las que, por ejemplo, un servicio como una puerta de enlace del vehículo confía en una VM de infoentretenimiento comprometida solo porque tiene la dirección IP correcta.

El aislamiento aplicado por hardware y los protocolos de cuarentena automatizados protegen la plataforma. Los dispositivos pares dentro de la malla SDV usan la autenticación y la certificación basadas en DICE, como se detalla en la siguiente sección, para ayudar a identificar y contener la ejecución de código no autorizado o la manipulación de la configuración.

TLS basado en DICE para proteger la comunicación de VM a VM

Fundamentación de la identidad del host en la realidad

La regla de oro de DICE (motor de composición de identificadores de dispositivos): Si cambia una sola línea de código en el firmware (incluso una actualización menor o un exploit malicioso), el identificador de dispositivo compuesto (CDI) derivado cambia por completo, lo que genera una clave de alias completamente diferente.

DICE y TLS (seguridad de la capa de transporte) se integran para resolver el desafío fundamental de la arquitectura de confianza cero: autenticar una máquina y, al mismo tiempo, verificar la integridad de su software.

La combinación de la identificación respaldada por hardware de DICE y el protocolo de enlace encriptado de TLS permite que una máquina receptora verifique la identidad del llamador y su estado de software exacto.

Los certificados tradicionales solo demuestran la posesión de un secreto; no pueden detectar la manipulación del firmware. DICE aborda este problema a través de capas de arranque medidas:

• El secreto único del dispositivo (UDS): Un secreto criptográfico aleatorio que se genera durante la fabricación. Solo el cargador de arranque de primera etapa puede acceder al UDS; permanece inaccesible para todo el software y las interfaces externas.
• Mediciones en capas (el identificador de dispositivo compuesto): La ROM de hardware inicia la cadena mediante el hash del UDS con el código exacto y la configuración de la siguiente capa de firmware. Esto crea un CDI, que luego se encadena de forma secuencial a medida que se inicia cada capa posterior.

Los controles de acceso estrictos rigen las interacciones de servicio dentro de la malla AAOS SDV. Al igual que todo el software de AAOS SDV, estos controles de acceso se autentican y su integridad se protege a nivel del dispositivo y en todos los dispositivos de la malla a través de la autenticación basada en DICE.

Control de acceso en capas

AAOS SDV emplea una estrategia de defensa en profundidad para habilitar actualizaciones dinámicas de vehículos sin comprometer los mecanismos de acceso. Este modelo se basa en dos capas de confianza principales:

1. Permisos a nivel del servicio: Definen los recursos específicos a los que un servicio en una VM determinada puede acceder o exponer en la malla.
2. Permisos a nivel de la VM: Definen los límites de comunicación entre VMs para todos los servicios alojados en una VM específica.

Este modelo permite que los OEMs equilibren la seguridad con la capacidad de actualización. Para los servicios que no son sensibles a la seguridad, las políticas permisivas a nivel de la VM permiten la instalación a través de actualizaciones de APEX livianas en lugar de volver a implementar la VM completa.

Por el contrario, los permisos para las señales sensibles a la seguridad deben estar codificados de forma rígida en cada VM. La desventaja es que, para introducir un servicio sensible a la seguridad en una VM nueva, se debe actualizar el sistema de permisos a nivel de la VM en todo el sistema. Esto requiere una actualización de todas las VMs dentro de la malla.

Conclusión

AAOS SDV extiende la arquitectura de seguridad de Android para abordar requisitos automotrices específicos a través de un enfoque de diseño de seguridad integral. Al aprovechar la virtualización para el aislamiento de dominios y aplicar políticas de acceso de "denegación predeterminada", la plataforma establece un entorno resistente para los vehículos definidos por software. La integridad criptográfica se mantiene a través de la verificación en tiempo real del código ejecutado aplicada por hardware.

La plataforma integra ciclos de vida de seguridad continuos, desde la gestión de vulnerabilidades proactiva hasta la verificación de identidad basada en hardware a través de DICE. Estas defensas de varias capas permiten que los OEMs equilibren la capacidad de actualización de funciones avanzadas con la seguridad sólida necesaria para los entornos automotrices modernos. Las especificaciones técnicas y los detalles de implementación están disponibles en la página Descripción general de AAOS SDV.