Seguridad

Para evitar la ejecución de cargas útiles arbitrarias dentro de una pVM, el framework de virtualización de Android (AVF) usa un enfoque de seguridad en capas en el que cada capa agrega aplicaciones adicionales. A continuación, se muestra una lista de las capas de seguridad de AVF:

  • Android garantiza que solo aquellas apps con permisos de pVM puedan crear o inspeccionar pVM.

  • Bootloader: El bootloader garantiza que solo las imágenes de pVM firmadas por Google o proveedores de dispositivos puedan iniciarse y respeta el procedimiento de inicio verificado de Android. Esta arquitectura implica que las apps que ejecutan pVM no pueden empaquetar sus propios kernels.

  • pVM proporciona defensa en profundidad, como con SELinux, para las cargas útiles que se ejecutan en la pVM. La defensa en profundidad no permite asignar datos como ejecutables (neverallow execmem) y garantiza que W^X se aplique a todos los tipos de archivos.

Modelo de seguridad

La confidencialidad, la integridad y la disponibilidad (tríada CID) conforman un modelo diseñado para guiar las políticas de seguridad de la información:

  • La confidencialidad es un conjunto de reglas que limitan el acceso a la información.
  • La integridad es la garantía de que la información es confiable y precisa.
  • La disponibilidad es una garantía de acceso confiable a la información por parte de entidades autorizadas.

Integridad y confidencialidad

La confidencialidad proviene de las propiedades de aislamiento de memoria que aplica el hipervisor de la pKVM. Esta hace un seguimiento de la propiedad de la memoria de las páginas de memoria física individuales y de cualquier solicitud de los propietarios de páginas para que se compartan. La pKVM garantiza que solo las pVM con derechos (hosts e invitados) tengan la página determinada asignada en sus tablas de páginas de la etapa 2 controladas por el hipervisor. Esta arquitectura mantiene que el contenido de la memoria que pertenece a una pVM sigue siendo privado, a menos que el propietario lo comparta de manera explícita con otra pVM.

Las restricciones para mantener la confidencialidad también se extienden a cualquier entidad del sistema que realice accesos a la memoria en nombre de las pVM, es decir, los dispositivos compatibles con DMA y los servicios que se ejecutan en capas con más privilegios. Los proveedores de sistema en chip (SoC) deben cumplir con un nuevo conjunto de requisitos antes de poder admitir la pKVM. De lo contrario, no se podrá proporcionar confidencialidad.

La integridad se aplica a los datos en la memoria y al procesamiento. Las pVM no pueden realizar las siguientes acciones:

  • Modificar la memoria de cada uno sin consentimiento
  • Influir en el estado de la CPU de cada uno.

El hipervisor aplica estos requisitos. Sin embargo, también surgen problemas relacionados con la integridad de los datos con el almacenamiento virtual de datos, cuando se deben aplicar otras soluciones, como dm-verity o AuthFS.

Estos principios no difieren del aislamiento de procesos que ofrece Linux, en el que el acceso a las páginas de memoria se controla con tablas de páginas de etapa 1 y el kernel cambia de contexto entre procesos. Sin embargo, la parte EL2 de la pKVM, que aplica estas propiedades, tiene tres órdenes de magnitud menos de superficie de ataque en comparación con todo el kernel de Linux (aproximadamente 10,000 en comparación con 20 millones de líneas de código) y, por lo tanto, ofrece una seguridad más sólida en los casos de uso que son demasiado sensibles como para depender del aislamiento de procesos.

Debido a su tamaño, la pKVM se presta a la verificación formal. Respaldamos activamente la investigación académica, que tiene como objetivo demostrar formalmente estas propiedades en el objeto binario de la pKVM.

En el resto de esta página, se abordan las garantías de integridad y confidencialidad que proporciona cada componente en torno a una pKVM.

Hipervisor

La pKVM es un hipervisor basado en KVM que aísla las pVM y Android en entornos de ejecución que no son de confianza mutua. Estas propiedades se conservan en caso de que se produzca un compromiso en cualquier pVM, incluido el host. Los hipervisores alternativos que cumplen con AVF deben proporcionar propiedades similares.

  • Una pVM no puede acceder a una página que pertenece a otra entidad, como una pVM o un hipervisor, a menos que el propietario de la página lo comparta de forma explícita. Esta regla incluye la pVM del host y se aplica a los accesos de CPU y DMA.

  • Antes de que una página que usa una pVM se muestre al host, como cuando se destruye la pVM, se limpia.

  • La memoria de todas las pVM y el firmware de pVM del inicio de un dispositivo se limpia antes de que se ejecute el bootloader del SO en el siguiente inicio del dispositivo.

  • Cuando se conecta un depurador de hardware, como SJTAG, una pVM no puede acceder a sus claves creadas con anterioridad.

  • El firmware de la pVM no se inicia si no puede verificar la imagen inicial.

  • El firmware de la pVM no se inicia si se ve comprometida la integridad de instance.img.

  • La cadena de certificados del DICE y los identificadores de dispositivos compuestos (CDI) proporcionados a una instancia de pVM pueden derivar solo de esa instancia en particular.

SO invitado

Microdroid es un ejemplo de un SO que se ejecuta dentro de una pVM. Microdroid consta de un bootloader basado en U, GKI, un subconjunto del espacio de usuario de Android y un selector de carga útil. Estas propiedades se mantienen en caso de que se produzca una vulneración en cualquier pVM, incluido el host. Los SO alternativos que se ejecuten en una pVM deben proporcionar propiedades similares.

  • Microdroid no se iniciará si no se pueden verificar boot.img, super.img, vbmeta.img o vbmeta\_system.img.

  • Microdroid no se inicia si falla la verificación del APK.

  • La misma instancia de Microdroid no se iniciará incluso si se actualizó el APK.

  • Microdroid no se iniciará si alguno de los APEX no pasa la verificación.

  • Microdroid no se iniciará (ni se iniciará con un estado inicial limpio) si el instance.img se modifica fuera de la pVM invitada.

  • Microdroid proporciona certificación a la cadena de inicio.

  • Cualquier modificación (sin firmar) de las imágenes de disco compartidas con la pVM invitada provoca un error de E/S en el lado de la pVM.

  • La cadena de certificados DICE y los CDI proporcionados a una instancia de pVM pueden derivar solo de esa instancia en particular.

  • Las operaciones de escritura en un volumen de almacenamiento encriptado son confidenciales. Sin embargo, no hay protección contra reversión con el nivel de detalle de un bloque de encriptación. Además, otra manipulación externa arbitraria de un bloque de datos hace que ese bloque aparezca como elemento no utilizado para Microdroid, en lugar de que se detecte explícitamente como un error de E/S.

Android

Estas son propiedades que Android mantiene como host, pero que no se cumplen en caso de que se vulnere el host:

  • Una pVM invitada no puede interactuar directamente con otras pVM invitadas (por ejemplo, para realizar una conexión vsock).

  • Solo la VirtualizationService de la pVM del host puede hacer un canal de comunicación a una pVM.

  • Solo las apps que están firmadas con la clave de plataforma pueden solicitar permiso para crear o poseer pVMs, o para interactuar con ellas.

  • El identificador, llamado identificador de contexto (CID), que se usa para configurar conexiones vsock entre el host y la pVM no se vuelve a usar cuando se ejecuta la pVM del host. Por ejemplo, no puedes reemplazar una pVM en ejecución por otra.

Disponibilidad

En el contexto de las pVM, la disponibilidad se refiere a que el host asigna suficientes recursos a los invitados, de modo que estos puedan realizar las tareas para las que están diseñados.

Las responsabilidades del host incluyen programar las CPU virtuales de la pVM. A diferencia de los hipervisores de tipo 1 convencionales (como Xen), KVM toma la decisión explícita de diseño de delegar la programación de la carga de trabajo al kernel del host. Debido al tamaño y la complejidad de los programadores actuales, esta decisión de diseño reduce significativamente el tamaño de la base de procesamiento confiable (TCB) y permite que el host tome decisiones de programación más informadas para optimizar el rendimiento. Sin embargo, un host malicioso puede optar por no programar nunca un invitado.

De manera similar, la pKVM también delega el control de interrupciones físicas al kernel del host para reducir la complejidad del hipervisor y dejar al host a cargo de la programación. Se realizan esfuerzos para garantizar que el reenvío de invitados interrumpa solo la denegación del servicio (muy pocas, demasiadas o interrupciones mal enrutadas).

Por último, el proceso de supervisión de máquina virtual (VMM) del host es responsable de asignar memoria y proporcionar dispositivos virtuales, como una tarjeta de red. Una VMM maliciosa puede retener recursos del invitado.

Aunque la pKVM no proporciona disponibilidad a los invitados, el diseño protege la disponibilidad del host de invitados maliciosos, ya que este siempre puede interrumpir o finalizar a un invitado y reclamar sus recursos.

Inicio seguro

Los datos están vinculados a las instancias de una pVM, y el inicio seguro garantiza que se pueda controlar el acceso a los datos de una instancia. El primer inicio de una instancia la aprovisiona mediante la generación aleatoria de una sal secreta para la pVM y la extracción de detalles, como las claves públicas de verificación y los hashes, de las imágenes cargadas. Esta información se usa para verificar los inicios posteriores de la instancia de pVM y garantizar que los secretos de la instancia se liberen solo a las imágenes que aprueban la verificación. Este proceso se produce para cada etapa de carga dentro de la pVM: firmware de pVM, ABL de pVM, Microdroid, etcétera.

DICE proporciona a cada etapa de carga un par de claves de certificación, cuya parte pública se certifica en el certificado DICE de esa etapa. Este par de claves puede cambiar entre arranques, por lo que también se deriva un secreto de sellado que es estable para la instancia de VM en todos los reinicios y, como tal, es adecuado para proteger el estado persistente. El secreto de sellado es muy valioso para la VM, por lo que no debe usarse directamente. En su lugar, las claves de sellado deben derivarse del secreto de sellado, y este se debe destruir lo antes posible.

Cada etapa entrega un objeto CBOR codificado de manera determinista a la siguiente etapa. Este objeto contiene secretos y la cadena de certificados DICE, que contiene información de estado acumulada, por ejemplo, si la última etapa se cargó de forma segura.

Dispositivos desbloqueados

Cuando se desbloquea un dispositivo con fastboot oem unlock, se borran los datos del usuario. Este proceso protege los datos del usuario del acceso no autorizado. Los datos privados de una pVM también se invalidan cuando se desbloquea un dispositivo.

Una vez desbloqueado, el propietario del dispositivo puede volver a escribir en la memoria flash de particiones que suelen estar protegidas por el inicio verificado, incluidas las particiones que contienen la implementación de la pKVM. Por lo tanto, no se confiará en la pKVM de un dispositivo desbloqueado para mantener el modelo de seguridad.

Los terceros remotos pueden observar este estado potencialmente inseguro inspeccionando el estado de inicio verificado del dispositivo en un certificado de certificación de claves.