Seguridad

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

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

  • Cargador de arranque: el cargador de arranque garantiza que solo las imágenes pVM firmadas por Google o los proveedores de dispositivos puedan arrancar y respeta el procedimiento de arranque verificado de Android . Esta arquitectura implica que las aplicaciones que ejecutan pVM no pueden agrupar sus propios núcleos.

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

Modelo de seguridad

Confidencialidad, integridad y disponibilidad (tríada CIA), conforman un modelo diseñado para orientar 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 garantía de acceso confiable a la información por parte de entidades autorizadas.

Confidencialidad e integridad

La confidencialidad surge de las propiedades de aislamiento de memoria impuestas por el hipervisor pKVM. pKVM rastrea la propiedad de la memoria de las páginas de memoria física individuales y cualquier solicitud de los propietarios para compartir páginas. pKVM garantiza que solo los pVM autorizados (host e invitados) tengan la página determinada asignada en sus tablas de páginas de etapa 2 que están controladas por el hipervisor. Esta arquitectura mantiene que el contenido de la memoria propiedad de un pVM permanece privado a menos que el propietario lo comparta explícitamente con otro pVM.

Las restricciones para mantener la confidencialidad también se extienden a cualquier entidad en el sistema que realice accesos a la memoria en nombre de pVM, es decir, dispositivos y servicios con capacidad DMA que se ejecutan en capas más privilegiadas . Los proveedores de System-on-Chip (SoC) deben satisfacer un nuevo conjunto de requisitos antes de poder admitir pKVM. De lo contrario, no se puede proporcionar confidencialidad.

La integridad se aplica a los datos en la memoria y la computación. Los pVM no pueden:

  • Modificar la memoria del otro sin consentimiento.
  • Influyen en el estado de la CPU de cada uno.

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

Estos principios no son diferentes del aislamiento de procesos que ofrece Linux, donde el acceso a las páginas de memoria se controla con tablas de páginas de la etapa 1 y el contexto del kernel cambia entre procesos. Sin embargo, la porción EL2 de pKVM, que aplica estas propiedades, tiene aproximadamente la mitad de la superficie de ataque en comparación con todo el kernel de Linux (aproximadamente 10 mil frente a 20 millones de líneas de código) y, por lo tanto, ofrece una mayor seguridad para usar casos que son demasiado sensibles para confiar. sobre el aislamiento de procesos.

Dado su tamaño, un pKVM se presta a una verificación formal. Apoyamos activamente la investigación académica, cuyo objetivo es probar formalmente estas propiedades en el binario pKVM real.

El resto de esta página aborda las garantías de confidencialidad e integridad que proporciona cada componente de un pKVM.

Hipervisor

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

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

  • Antes de que una página utilizada por un pVM se devuelva al host, como cuando se destruye el pVM, se borra.

  • La memoria de todos los pVM y el firmware de pVM del inicio de un dispositivo se borra antes de que se ejecute el cargador de arranque del sistema operativo en el inicio posterior del dispositivo.

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

  • El firmware pVM no arranca si no puede verificar la imagen inicial.

  • El firmware pVM no arranca si la integridad del instance.img está comprometida.

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

SO invitado

Microdroid es un ejemplo de un sistema operativo que se ejecuta dentro de un pVM. Microdroid consta de un gestor de arranque basado en U, GKI, un subconjunto del espacio de usuario de Android y un iniciador de carga útil. Estas propiedades se mantienen en caso de un compromiso dentro de cualquier pVM, incluido el host. Los sistemas operativos alternativos que se ejecutan en un pVM deberían proporcionar propiedades similares.

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

  • Microdroid no arrancará si falla la verificación del APK.

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

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

  • Microdroid no arrancará (o arrancará con un estado inicial limpio) si el instance.img se modifica fuera del pVM invitado.

  • Microdroid proporciona certificación de la cadena de arranque.

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

  • Los BCC y CDI proporcionados a una instancia de pVM solo pueden derivarse de esa instancia en particular.

  • Las escrituras en un volumen de almacenamiento cifrado son confidenciales; sin embargo, no existe protección de reversión en la granularidad de un bloque de cifrado. Además, otras manipulaciones externas arbitrarias de un bloque de datos hacen que ese bloque aparezca como basura para Microdroid, en lugar de ser detectado explícitamente como un error de E/S.

Androide

Estas son propiedades mantenidas por Android como host, pero no son válidas en caso de que el host se vea comprometido:

  • Un pVM invitado no puede interactuar directamente con otros pVM invitados (por ejemplo, para realizar una conexión vsock ).

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

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

  • El identificador, llamado identificador de contexto (CID), utilizado para configurar conexiones vsock entre el host y pVM no se reutiliza cuando el pVM del host se está ejecutando. Por ejemplo, no puede reemplazar un pVM en ejecución por otro.

Disponibilidad

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

Las responsabilidades del host incluyen la programación de las CPU virtuales del pVM. KVM, a diferencia de los hipervisores tipo 1 convencionales (como Xen), toma la decisión de diseño explícita de delegar la programación de la carga 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 informática confiable (TCB) y permite al host tomar decisiones de programación más informadas para optimizar el rendimiento. Sin embargo, un anfitrión malintencionado puede optar por no programar nunca un invitado.

De manera similar, 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 hacen esfuerzos para garantizar que el reenvío de interrupciones de invitados solo resulte en una denegación de servicio (muy pocas, demasiadas o interrupciones mal enrutadas).

Finalmente, el proceso de monitorización 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 pKVM no proporciona disponibilidad a los invitados, el diseño protege la disponibilidad del host de invitados maliciosos porque el host siempre puede adelantarse o cancelar un invitado y reclamar sus recursos.

Arranque seguro

Los datos están vinculados a instancias de un pVM y el arranque seguro garantiza que se pueda controlar el acceso a los datos de una instancia. El primer arranque de una instancia la aprovisiona generando aleatoriamente un salt secreto para el pVM y extrayendo detalles, como claves públicas de verificación y hashes, de las imágenes cargadas. Esta información se utiliza para verificar los arranques posteriores de la instancia de pVM y garantizar que los secretos de la instancia se revelen solo a las imágenes que pasen la verificación. Este proceso ocurre para cada etapa de carga dentro del pVM: firmware de pVM, pVM ABL, Microdroid, etc.

DICE proporciona a cada etapa de carga un par de claves de certificación, cuya parte pública está certificada en la entrada BCC para 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 durante los reinicios y, como tal, es adecuado para proteger el estado persistente. El secreto de sellado es muy valioso para el VM, por lo que no debe utilizarse directamente. En cambio, las claves de sellado deben derivarse del secreto de sellado y el secreto de sellado debe destruirse lo antes posible.

Cada etapa entrega un objeto CBOR codificado de manera determinista a la siguiente etapa. Este objeto contiene secretos y BCC, 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 , los datos del usuario se borran. Este proceso protege los datos del usuario del acceso no autorizado. Los datos que son privados para un pVM también se invalidan cuando se produce el desbloqueo de un dispositivo.

Una vez desbloqueado, el propietario del dispositivo puede actualizar las particiones que normalmente están protegidas mediante arranque verificado, incluidas las particiones que contienen la implementación pKVM. Por lo tanto, no se confiará en que pKVM en un dispositivo desbloqueado mantenga el modelo de seguridad.

Las partes remotas pueden observar este estado potencialmente inseguro inspeccionando el estado de inicio verificado del dispositivo en un certificado de atestación de clave.