Seguridad

Para evitar que se ejecuten 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 de políticas 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 se puedan iniciar imágenes de pVM firmadas por Google o los proveedores de dispositivos, y respeta el procedimiento de inicio verificado de Android. Esta arquitectura implica que las apps que ejecutan pVM no pueden agrupar sus propios kernels.

  • La pVM proporciona una 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 limita 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.

Confidencialidad e integridad

La confidencialidad proviene de las propiedades de aislamiento de memoria que aplica el hipervisor de pKVM. pKVM realiza un seguimiento de la propiedad de la memoria de las páginas de memoria física individuales y de las solicitudes de los propietarios para que se compartan las páginas. pKVM garantiza que solo las pVM con derechos (host y huéspedes) tengan la página determinada asignada en sus tablas de páginas de etapa 2 que controla el hipervisor. Esta arquitectura mantiene que el contenido de la memoria que pertenece a una pVM permanece privado, a menos que el propietario lo comparta de forma 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 sistemas integrados en chip (SoC) deben cumplir con un nuevo conjunto de requisitos para poder admitir pKVM. De lo contrario, no se puede garantizar la confidencialidad.

La integridad se aplica a los datos en la memoria y el procesamiento. Las pVM no pueden hacer lo siguiente:

  • Modificar la memoria de los demás sin consentimiento
  • Influir en el estado de la CPU de cada uno.

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

Estos principios no son diferentes 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 realiza conmutaciones 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 prácticos 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. Apoyamos de forma activa la investigación académica, cuyo objetivo es probar formalmente estas propiedades en el binario pKVM real.

En el resto de esta página, se abordan las garantías de confidencialidad e integridad que proporciona cada componente alrededor de un pKVM.

Hipervisor

pKVM es un hipervisor basado en KVM que aísla las pVM y Android en entornos de ejecución que no confían entre sí. Estas propiedades se mantienen en caso de que se produzca una violación de la seguridad en cualquier pVM, incluido el host. Los hipervisores alternativos que cumplen con la AVF deben proporcionar propiedades similares.

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

  • Antes de que una página que usa una pVM se devuelva al host, por ejemplo, cuando se destruye la pVM, se borra.

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

  • Cuando se conecta un depurador de hardware, como SJTAG, una pVM no puede acceder a sus claves acuñadas anteriormente.

  • El firmware de 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 de DICE y los identificadores de dispositivos compuestos (CDI) que se proporcionan a una instancia de pVM solo pueden derivarse 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-boot, 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 ejecutan 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 iniciará 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 APEXes falla en la verificación.

  • Microdroid no se iniciará (o se iniciará con un estado inicial limpio) si se modifica instance.img 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 de DICE y los CDI proporcionados a una instancia de pVM solo pueden derivarse de esa instancia en particular.

  • Las operaciones de escritura en un volumen de almacenamiento encriptado son confidenciales, pero no hay protección contra la reversión en 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 son válidas en caso de que se comprometa el host:

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

  • Solo el VirtualizationService en la pVM host puede crear un canal de comunicación con una pVM.

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

  • 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 al host que asigna recursos suficientes a los invitados para que puedan realizar las tareas para las que están diseñadas.

Las responsabilidades del host incluyen programar las CPU virtuales de la pVM. KVM, a diferencia de los hipervisores convencionales de tipo 1 (como Xen), toma la decisión de diseño explícita de delegar la programación de cargas de trabajo al kernel del host. Dado el 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 fundamentadas para optimizar el rendimiento. Sin embargo, un host malicioso puede optar por no programar nunca un invitado.

Del mismo modo, la pKVM también delega el manejo 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 los resultados solo en una denegación del servicio (muy pocas, demasiadas o interrupciones mal enrutadas).

Por último, el proceso del supervisor de máquina virtual (VMM) del host es responsable de asignar memoria y proporcionar dispositivos virtuales, como una tarjeta de red. Un VMM malicioso 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 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 publiquen solo en las imágenes que aprueben la verificación. Este proceso ocurre 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 está certificada en el certificado de DICE para esa etapa. Este par de claves puede cambiar entre inicios, por lo que también se deriva un secreto de sellado que es estable para la instancia de VM en todos los reinicios y, por lo tanto, es adecuado para proteger el estado persistente. El secreto de sellado es muy valioso para la VM, por lo que no se debe usar directamente. En su lugar, las claves de sellado deben derivarse del secreto de sellado, y este debe destruirse lo antes posible.

Cada etapa entrega un objeto CBOR codificado de forma determinista a la etapa siguiente. Este objeto contiene secretos y la cadena de certificados de DICE, que contiene información de estado acumulada, como 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 contra el acceso no autorizado. Los datos que son privados para una pVM también se invalidan cuando se produce el desbloqueo de 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 el pKVM de un dispositivo desbloqueado para mantener el modelo de seguridad.

Las partes remotas pueden observar este estado potencialmente inseguro si inspeccionan el estado de inicio verificado del dispositivo en un certificado de certificación de claves.