Casos de uso

En esta página, se incluyen casos de uso comunes de AVF.

Compilación aislada

Como enclave seguro de software, una máquina virtual (VM) protegida proporciona un entorno seguro para compilar código sensible a la seguridad. Este entorno permite trasladar la compilación de bootclasspath y los archivos JAR del servidor del sistema (que se activan con una actualización de APEX) desde el inicio temprano hasta antes del reinicio, y reduce significativamente el tiempo de inicio posterior a la actualización de APEX.

La implementación se encuentra en el APEX com.android.compos. Este componente es opcional y se puede incluir con un archivo makefile.

Compilación aislada

Figura 1: Compilación de archivos JAR en actualizaciones de Mainline Compilación de archivos JAR en actualizaciones de Mainline

El objetivo de seguridad es compilar de forma veraz la entrada verificada y producir el resultado de forma aislada. Android, como cliente no confiable, no puede alterar el resultado de la compilación de ninguna manera, excepto provocar que falle (cuando Android recurre a la compilación en tiempo de inicio).

El servicio de compilación de la VM genera una firma solo si no hay errores durante toda la compilación. Android puede recuperar la clave pública de la VM para verificar la firma.

La clave de la VM se genera a partir del perfil de DICE de la VM, que se define por los APEX y los APK que se activan en la VM, además de otros parámetros de la VM, como la capacidad de depuración.

Para determinar si la clave pública no proviene de una VM inesperada, Android inicia la VM para determinar si la clave es correcta. La VM se inicia en el inicio temprano después de cada actualización de APEX.

Con el inicio verificado de las VMs protegidas, el servicio de compilación solo ejecuta código verificado. Como resultado, el código puede determinar que solo se acepten las entradas que satisfagan ciertas condiciones, por ejemplo, aceptar un archivo de entrada solo cuando su nombre y el resumen de fs-verity se definan en una lista de entidades permitidas.

Las APIs expuestas desde la VM son superficies de ataque. Se supone que todos los archivos y parámetros de entrada provienen de un cliente no confiable, y deben verificarse y aprobarse antes del procesamiento.

La VM verifica la integridad de los archivos de entrada y salida, y los archivos se almacenan en Android como un servidor de archivos no confiable, de la siguiente manera:

  • El contenido de un archivo de entrada se debe verificar antes de usarlo con el algoritmo fs-verity. Para que un archivo de entrada esté disponible en la VM, su hash raíz debe proporcionarse en un contenedor (APK) que contribuya al perfil de DICE de la VM. Con el hash raíz de confianza, un atacante no puede manipular la entrada sin que se detecte.
  • Se debe mantener la integridad del archivo de salida en la VM. Incluso si un archivo de salida se almacena en Android, durante la generación, la integridad se mantiene con el mismo formato de árbol fs-verity, pero se puede actualizar de forma dinámica. El archivo de salida final se puede identificar con el hash raíz, que está aislado en la VM. El servicio en la VM protege los archivos de salida con una firma.

Entorno de desarrollo de Linux

Tradicionalmente, Android fue el único sistema operativo importante que no permitía a los usuarios desarrollar apps en la plataforma. Con la introducción del entorno de desarrollo de Linux, nuestro objetivo es proporcionar un entorno de desarrollo basado en Linux a los usuarios de Android que son desarrolladores. En el futuro, planeamos expandir esta iniciativa para que nuestros socios puedan implementar casos de uso innovadores de VMs, como ejecutar apps con interfaces gráficas de usuario y hasta juegos.

El entorno de desarrollo de Linux está disponible en dispositivos seleccionados y se ejecuta en una máquina virtual no protegida.

Caso de uso del entorno de desarrollo de Linux

Figura 2: Caso de uso del entorno de desarrollo de Linux.

El flujo general es el siguiente:

  1. Para usar el entorno de desarrollo de Linux, habilita las opciones para desarrolladores.
  2. Después de habilitar las opciones para desarrolladores, la app de Terminal aparecerá en el selector de inicio.
  3. Inicia la app de Terminal desde el selector de inicio.
  4. Si es necesario, la app de Terminal descargará la imagen del SO desde Play.
  5. La app de Terminal usa Android Virtualization Framework (AVF) para crear una máquina virtual (VM).
  6. Luego, AVF ejecuta la VM con la imagen del SO.
  7. La máquina virtual inicia el SO desde la imagen.
  8. Después de que se inicie la VM, WebView en la app de Terminal se conectará a un servicio web en la máquina virtual. Este servicio proporciona acceso a la terminal a través de HTTP.
  9. Para interactuar con la terminal, ingresa comandos y ve el resultado en la app.

Los componentes de alto nivel de la VM de Linux son los siguientes:

  • App de terminal: Es una aplicación para Android que proporciona una interfaz de terminal. Usa un WebView para conectarse a un servicio web que se ejecuta en la VM para la interacción. Esta app está inhabilitada de forma predeterminada. Actívala en Configuración para desarrolladores.
  • Android Virtualization Framework (AVF): Es el subsistema existente de Android para la creación y administración de VMs. Requiere una modificación mínima para admitir imágenes de SO personalizadas para esta función.
  • Máquina virtual: Es una VM que genera AVF. Aloja el servicio de terminal y AVF lo crea específicamente para la funcionalidad de la app de Terminal.
  • Imagen del SO: Es una imagen del SO basada en Debian y ligeramente modificada a partir de la imagen de Debian upstream. La app de Terminal descarga esta imagen desde un servidor externo de Google. Sirve como base para el funcionamiento de la VM.
  • Agente de invitado: Software nuevo en la VM. Informa el estado del SO a AVF y proporciona control de la máquina virtual.
  • ttyd: Es un software de código abierto que se ejecuta en la VM y que implementa la emulación de terminal a través de HTTP. La WebView de la app de Terminal se conecta a él.
  • Tethering Manager: Es un subsistema de Android existente. Proporciona acceso a la red a la máquina virtual vinculándola al dispositivo con Android.

Seguridad del contenido en el dispositivo

Content Safety On-device es una solución de seguridad del contenido que preserva la privacidad y que creó el equipo de Content Safety On-device. Realiza la clasificación de seguridad del contenido para varios productos de Google en dispositivos de 1P/3P y protege a más de mil millones de usuarios del contenido abusivo, sin necesidad de enviar datos del usuario a los servidores de Google. Está diseñado para cumplir con los principios de Private Compute Core (PCC) y verificar la comunicación transparente y que preserva la privacidad entre el cliente y la máquina virtual (VM), además de evitar la filtración de datos del usuario. Se puede usar para habilitar la detección de abusos en dispositivos, como la detección de amenazas en vivo de Play Protect.

En este caso de uso, el sistema utiliza máquinas virtuales protegidas para ejecutar su clasificación de modelos para la detección de amenazas en vivo de Play Protect, lo que mejora significativamente la seguridad de sus modelos y protecciones. Esto evita la ingeniería inversa y la manipulación por parte de los atacantes, incluso en dispositivos con acceso de administrador, ya que solo se verifica que se ejecute el código aprobado y sus operaciones se ocultan de los procesos externos.

Los flujos de alto nivel son los siguientes:

  1. La detección de amenazas en vivo envía un ping a Private Compute Services para iniciar la VM. Private Compute Services es un intermediario centrado en la privacidad entre el PCC y el servidor en la nube.
  2. Private Compute Services inicia la VM y obtiene su clave pública de ella.
  3. Los Servicios de Private Compute entregan la propiedad de la VM a la detección de amenazas en vivo de Play Protect
  4. Los Servicios de Private Compute envían la certificación y la clave pública al servidor.
  5. El servidor verifica la certificación y encripta las protecciones con la clave pública de la VM
  6. Luego, el servidor envía las protecciones encriptadas de vuelta al dispositivo.
  7. Luego, la detección de amenazas en vivo en el dispositivo puede utilizar la protección encriptada dentro de la VM. La VM es la única entidad con la clave privada que puede desencriptar las protecciones.

Los componentes de alto nivel son los siguientes:

  • Servidor: Encripta y entrega protecciones encriptadas a la VM
  • Servicios de Private Compute: Se usan para iniciar la VM y mediar la comunicación con ella, y mostrar transparencia de que no se transfieren datos del usuario a través de Astrea al servidor.
  • Detección de amenazas en vivo de Play Protect:
    • Contiene y usa clasificadores de modelos proporcionados por Content Safety en el dispositivo
    • Acepta la propiedad de la VM y la conserva para su uso en la clasificación.
    • Inicia y detiene la VM según sea necesario.

OEM

Un OEM puede usar el AVF para casos de uso personalizados. Por ejemplo, OPPO usa AVF para habilitar su espacio de procesamiento privado basado en IA. La primera aplicación de este espacio proporciona una solución de control de riesgos en el dispositivo para los clientes de la app, que se ejecuta en una máquina virtual. El sistema contrarresta las amenazas de actividades ilícitas y ofrece protección contra diversos peligros.