AAOS SDV - Diseño centrado en la seguridad

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

Base: Aislamiento de dominios

Virtualización para aislar instancias alojadas de forma conjunta

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

Si bien las instancias de SDV de AAOS proporcionan mecanismos de aislamiento internos, suele ser 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

El SDV de AAOS 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 rechazo predeterminado

El SDV de AAOS sigue el modelo de aislamiento basado en el ID de usuario (UID) de Android para configurar una zona 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 las capacidades de la interfaz de sistema operativo portátil (POSIX) para limitar estrictamente las operaciones y las combinamos 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 comprobada

El SDV de AAOS integra la infraestructura madura de respuesta de seguridad y gestión de vulnerabilidades de Android para identificar, clasificar, corregir y divulgar los hallazgos de seguridad. Este ciclo de vida incorpora análisis automatizados continuos, pruebas de penetración anuales detalladas y una inteligencia impulsada por 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 hace un seguimiento de la correcció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 exhaustivas para garantizar la resiliencia de la plataforma a largo plazo.

Integridad: Garantiza una entrega segura de software

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

Authenticated Software Delivery

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

En segundo lugar, usamos paquetes de 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 el SDV de AAOS, APEX trata la firma de código como un contrato continuo que se aplica por hardware. APEX garantiza que la ejecución de código malicioso se mitigue a través de cuatro pilares fundamentales: 

1. Almacenamiento inmutable

• El mecanismo: El kernel de Android ejecuta en bucle el archivo apex_payload.img directamente como un dispositivo de almacenamiento sin procesar con el bucle de retorno 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, ya que 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 sobre la marcha. Si un atacante modifica un bloque sin procesar en la memoria flash, el kernel detecta la discrepancia de hash y detiene la ejecución de inmediato.

3. Aislamiento estricto

• El mecanismo: Se aplican las reglas de aislamiento de procesos, como se describe en la sección Aislamiento de procesos, para crear una zona 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 usuarios y datos, lo que restringe el acceso, a menos que se comparta de forma explícita. 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 de "activo/copia de seguridad" para habilitar reversiones con doble búfer. El APEX que se instala 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 "fallida" durante el inicio anticipado. El sistema intercambia de forma instantánea los vínculos simbólicos de vuelta 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 con seguridad de 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. En el caso de los componentes nuevos desarrollados para el SDV de AAOS, priorizamos la seguridad de la memoria.

Rust como lenguaje principal

El SDV de AAOS se orienta a sistemas pequeños con requisitos de disponibilidad rápida, lo que 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 el 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, a la vez que admite la capacidad de procesamiento del equipo cuando se escribe código nativo.

Confianza distribuida: Control de acceso y red

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

Aprovisionamiento de dispositivos y mallas

La malla de SDV de AAOS 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 en el 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 de un vehículo confía en una VM de infoentretenimiento vulnerada solo porque tiene la dirección IP correcta.

El aislamiento aplicado por hardware y los protocolos de cuarentena automatizados protegen la plataforma. Los dispositivos de intercambio de tráfico dentro de la malla de 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 autorizada o la manipulación de la configuración.

TLS basada en DICE para proteger la comunicación entre VMs

Fundamentar la identidad del host en la realidad

La regla de oro del DICE (Device Identifier Composition Engine): 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 totalmente 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 emisor y su estado de software exacto.

Los certificados tradicionales solo demuestran la posesión de un secreto, pero no pueden detectar la manipulación del firmware. DICE aborda este problema a través de las capas de inicio medido:

• El secreto único del dispositivo (UDS): Es un secreto criptográfico aleatorio que se genera durante la fabricación. Solo el bootloader de la primera etapa puede acceder al UDS; permanece inaccesible para todos los demás softwares y las interfaces externas.
• Mediciones en capas (el identificador de dispositivo compuesto): La ROM de hardware inicia la cadena aplicando un algoritmo de hash al 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 los servicios dentro de la malla de SDV de AAOS. Al igual que todo el software de SDV de AAOS, 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 por capas

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

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

Este modelo permite que los OEM 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 ligeras de APEX en lugar de volver a implementar la VM por completo.

Por el contrario, los permisos para los indicadores sensibles a la seguridad deben estar codificados en cada VM. La desventaja es que, para introducir un servicio sensible a la seguridad en una VM nueva, se deben actualizar los 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

El SDV de AAOS extiende la arquitectura de seguridad de Android para abordar requisitos automotrices específicos a través de un enfoque de seguridad por diseño. Aprovechando la virtualización para el aislamiento de dominios y aplicando políticas de acceso de "denegación predeterminada", la plataforma establece un entorno resiliente para los vehículos definidos por software. La integridad criptográfica se mantiene a través de la verificación sobre la marcha del código ejecutado, que se aplica por hardware.

La plataforma integra ciclos de vida de seguridad continuos, que van desde la gestión proactiva de vulnerabilidades hasta la verificación de identidad basada en hardware a través de DICE. Estas defensas de varias capas permiten que los OEM equilibren la capacidad de actualización de las 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 de descripción general de SDV de AAOS.