Cas d'utilisation

Cette page présente des cas d'utilisation courants pour AVF.

Compilation isolée

En tant qu'enclave logicielle sécurisée, une machine virtuelle (VM) protégée fournit un environnement sûr pour compiler du code sensible à la sécurité. Cet environnement permet de déplacer la compilation des fichiers JAR bootclasspath et du serveur système (déclenchée par une mise à jour APEX) du démarrage anticipé à avant le redémarrage, et réduit considérablement le temps de démarrage après la mise à jour APEX.

L'implémentation se trouve dans l'APEX com.android.compos. Ce composant est facultatif et peut être inclus à l'aide d'un makefile.

Compilation isolée

Figure 1. Compilation des fichiers JAR sur les mises à jour Mainline. Compiler des fichiers JAR sur les mises à jour Mainline

L'objectif de sécurité est de compiler fidèlement les entrées validées et de produire la sortie de manière isolée. Android, en tant que client non fiable, ne peut en aucun cas modifier la sortie de compilation, sauf en la faisant échouer (lorsque Android revient à la compilation au moment du démarrage).

Le service de compilation de la VM ne génère une signature que s'il n'y a aucune erreur pendant toute la compilation. Android peut récupérer la clé publique de la VM pour valider la signature.

La clé de la VM est générée à partir de son profil DICE, défini par les APEX et les APK montés sur la VM, en plus d'autres paramètres de VM, tels que la capacité de débogage.

Pour déterminer si la clé publique ne provient pas d'une VM inattendue, Android démarre la VM pour vérifier si la clé est correcte. La VM est démarrée au début du démarrage après chaque mise à jour APEX.

Avec le démarrage validé des VM protégées, le service de compilation n'exécute que du code validé. Le code peut donc déterminer d'accepter uniquement les entrées qui satisfont certaines conditions. Par exemple, il peut accepter un fichier d'entrée uniquement si son nom et le résumé fs-verity sont définis dans une liste d'autorisation.

Toutes les API exposées de la VM sont des surfaces d'attaque. Tous les fichiers et paramètres d'entrée sont supposés provenir d'un client non fiable. Ils doivent être vérifiés et examinés avant d'être traités.

L'intégrité des fichiers d'entrée et de sortie est vérifiée par la VM, avec les fichiers stockés sur Android en tant que serveur de fichiers non fiable, comme suit :

  • Le contenu d'un fichier d'entrée doit être validé avant utilisation à l'aide de l'algorithme fs-verity. Pour qu'un fichier d'entrée soit disponible dans la VM, son hachage racine doit être fourni dans un conteneur (APK) qui contribue au profil DICE de la VM. Grâce au hachage racine de confiance, un pirate informatique ne peut pas falsifier l'entrée sans être détecté.
  • L'intégrité du fichier de sortie doit être maintenue dans la VM. Même si un fichier de sortie est stocké sur Android, son intégrité est maintenue pendant la génération avec le même format d'arborescence fs-verity, mais il peut être mis à jour de manière dynamique. Le fichier de sortie final peut être identifié à l'aide du hachage racine, qui est isolé dans la VM. Le service de la VM protège les fichiers de sortie par signature.

Environnement de développement Linux

Android a toujours été le seul système d'exploitation majeur qui ne permet pas aux utilisateurs de développer des applications sur la plate-forme elle-même. Avec l'introduction de l'environnement de développement Linux, nous souhaitons fournir un environnement de développement basé sur Linux aux utilisateurs Android qui sont développeurs. À l'avenir, nous prévoyons d'étendre nos efforts pour permettre à nos partenaires d'implémenter des cas d'utilisation innovants de VM, comme l'exécution d'applications d'interface utilisateur graphique et même de jeux.

L'environnement de développement Linux est disponible sur certains appareils et s'exécute dans une machine virtuelle non protégée.

Cas d'utilisation de l'environnement de développement Linux

Figure 2. Cas d'utilisation de l'environnement de développement Linux.

Voici le flux général :

  1. Pour utiliser l'environnement de développement Linux, activez les options pour les développeurs.
  2. Une fois les options pour les développeurs activées, l'application Terminal s'affiche dans le lanceur d'applications de votre écran d'accueil.
  3. Lancez l'application Terminal depuis le lanceur d'applications.
  4. Si nécessaire, l'application Terminal télécharge l'image de l'OS depuis Play.
  5. L'application Terminal utilise le framework de virtualisation Android (AVF) pour créer une machine virtuelle (VM).
  6. AVF exécute ensuite la VM avec l'image de l'OS.
  7. La machine virtuelle démarre l'OS à partir de l'image.
  8. Une fois la VM démarrée, la WebView de l'application Terminal se connecte à un service Web de la machine virtuelle. Ce service fournit un accès au terminal via HTTP.
  9. Vous interagissez avec le terminal en saisissant des commandes et en affichant le résultat dans l'application.

Voici les principaux composants de la VM Linux :

  • Application Terminal : application Android fournissant une interface de terminal. Il utilise une WebView pour se connecter à un service Web exécuté dans la VM pour l'interaction. Cette application est désactivée par défaut. Activez-le dans les paramètres développeur.
  • Framework de virtualisation Android (AVF) : sous-système Android existant pour la création et la gestion de VM. Il nécessite une modification minimale pour prendre en charge les images d'OS personnalisées pour cette fonctionnalité.
  • Machine virtuelle : VM générée par AVF. Il héberge le service de terminal et AVF le crée spécifiquement pour la fonctionnalité de l'application Terminal.
  • Image de l'OS : image de l'OS basée sur Debian et légèrement modifiée à partir de Debian en amont. L'application Terminal télécharge cette image à partir d'un serveur Google externe. Il sert de base au fonctionnement de la VM.
  • Agent invité : nouveau logiciel dans la VM. Il indique l'état de l'OS à AVF et permet de contrôler la machine virtuelle.
  • ttyd : logiciel Open Source s'exécutant dans la VM et implémentant l'émulation de terminal sur HTTP. La WebView de l'application Terminal s'y connecte.
  • Gestionnaire de partage de connexion : un sous-système Android existant. Il fournit un accès réseau à la machine virtuelle en l'associant à l'appareil Android.

Sécurité des contenus sur l'appareil

Content Safety On-device est une solution de sécurité du contenu respectueuse de la confidentialité, créée par l'équipe Content Safety On-device. Il effectue la classification de la sécurité du contenu pour divers produits Google sur les appareils 1P/3P et protège plus d'un milliard d'utilisateurs contre les contenus abusifs, sans nécessiter l'envoi de données utilisateur aux serveurs Google. Il est conçu pour respecter les principes du Private Compute Core (PCC) afin de vérifier la transparence et la confidentialité des communications entre le client et la machine virtuelle (VM), et d'empêcher toute exfiltration des données utilisateur. Il peut être utilisé pour activer la détection des utilisations abusives sur les appareils, comme la détection des menaces en direct de Play Protect.

Dans ce cas d'utilisation, le système utilise des machines virtuelles protégées pour exécuter la classification de son modèle pour la détection des menaces en direct de Play Protect, ce qui améliore considérablement la sécurité de ses modèles et de ses protections. Cela empêche la rétro-ingénierie et la manipulation par des pirates informatiques, même sur les appareils rootés, en vérifiant que seul le code approuvé s'exécute et que ses opérations sont masquées des processus externes.

Voici les principaux flux :

  1. La détection des menaces en direct envoie un ping à Private Compute Services pour démarrer la VM. Les services de calcul confidentiel sont un intermédiaire axé sur la confidentialité entre le PCC et le serveur cloud.
  2. Private Compute Services démarre la VM et récupère sa clé publique.
  3. Les services Private Compute transfèrent la propriété de la VM à la détection des menaces en direct Play Protect
  4. Les services Private Compute envoient l'attestation et la clé publique au serveur.
  5. Le serveur valide l'attestation et chiffre les protections avec la clé publique de la VM.
  6. Le serveur renvoie ensuite les protections chiffrées à l'appareil.
  7. La détection des menaces en direct sur l'appareil peut ensuite utiliser la protection chiffrée au sein de la VM. La VM est la seule entité disposant de la clé privée permettant de déchiffrer les protections.

Voici les principaux composants :

  • Serveur : chiffre et fournit des protections chiffrées à la VM
  • Services de calcul privés : utilisés pour démarrer la VM, assurer la médiation de la communication avec la VM et montrer que les données utilisateur ne transitent pas par Astrea vers le serveur
  • Détection des menaces en direct de Play Protect :
    • Contient et utilise des classificateurs de modèle fournis par la sécurité du contenu sur l'appareil
    • Accepte la propriété de la VM et la conserve pour l'utiliser à des fins de classification
    • Démarre et arrête la VM selon les besoins.

OEM

Un OEM peut utiliser l'AVF pour des cas d'utilisation personnalisés. Par exemple, OPPO utilise AVF pour activer son espace de calcul privé de l'IA. La première application de cet espace fournit une solution de contrôle des risques sur l'appareil pour les clients d'applications, exécutée dans une machine virtuelle. Le système permet de contrer les menaces liées aux activités illicites et offre une protection contre divers dangers.