Cas d'utilisation

Ce document présente des cas d'utilisation courants de l'outil AVF.

Compilation isolée

En tant qu'enclave sécurisée par logiciel, une VM protégée offre un environnement sécurisé pour compiler du code sensible à la sécurité. Cet environnement permet de déplacer la compilation de bootclasspath et les fichiers JAR du serveur système (déclenchés par une mise à jour APEX) de un démarrage anticipé avant le redémarrage et réduit de manière significative le temps de démarrage des mises à jour.

La mise en œuvre se trouve com.android.compos APEX. Ce composant est facultatif et peut être inclus à l'aide d'un makefile.

Compilation isolée

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

L'objectif de sécurité est de compiler honnêtement les entrées vérifiées et de produire la sortie de façon isolée ; Android, en tant que client non approuvé, ne peut pas modifier la compilation autrement que de provoquer une défaillance (quand Android revient au démarrage compilation temporelle).

Le service de compilation de la VM ne génère une signature que s'il n'existe aucune pendant toute la compilation. Android peut récupérer la clé publique à partir de la VM pour la vérification de signature.

La clé de la VM est générée à partir du profil DICE de la VM, défini par les Apexes. et APK installés sur la VM, en plus d'autres paramètres de VM, tels que débogabilité.

Pour déterminer si la clé publique ne provient pas d'une VM inattendue, Android démarre la VM pour déterminer si la clé est correcte. La VM est démarrée au démarrage anticipé. après chaque mise à jour de l'apex.

Avec le démarrage validé de Protected VM, le service de compilation n'est exécuté du code source. Le code peut donc décider de n'accepter que les entrées qui satisfont certaines conditions, par exemple, n'accepter un fichier d'entrée que si son nom et le condensé fs-verity est défini dans une liste d'autorisation.

Toutes les API exposées de la VM sont des surfaces d'attaque. Tous les fichiers d'entrée et sont considérés comme provenant d'un client non approuvé. Ils doivent être vérifiés et vérifiées avant leur traitement.

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

  • Le contenu d'un fichier d'entrée doit être vérifié avant d'être utilisé à l'aide de la Algorithme fs-verity. Pour qu'un fichier d'entrée soit disponible dans la VM, son le hachage racine doit être fourni dans un conteneur (APK) qui contribue à Profil DICE de la VM. Avec le hachage racine de confiance, un attaquant ne peut pas falsifier avec l'entrée sans être détectée.
  • L'intégrité du fichier de sortie doit être maintenue dans la VM. Même si un fichier de sortie est stocké sur Android. Pendant la génération, est géré avec le même format d'arborescence fs-verity, mais peut être dynamique mis à jour. Le fichier de sortie final peut être identifié par le hachage racine, qui est isolé dans la VM. Le service de la VM protège la sortie les fichiers par signature.