Cas d'utilisation

Ce document présente les cas d'utilisation courants d'AVF.

Compilation isolée

En tant qu'enclave sécurisée par logiciel, une VM protégée fournit un environnement sécurisé permettant de 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.

L'objectif de sécurité est de compiler de manière fiable les entrées validées et de produire la sortie en mode isolé. En tant que client non approuvé, Android ne peut pas modifier la sortie de compilation d'une autre manière que de la faire échouer (lorsque Android revient à la compilation au démarrage).

Le service de compilation de la VM ne génère une signature que si aucune erreur ne se produit pendant toute la compilation. Android peut récupérer la clé publique de la VM pour la validation de signature.

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

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 précoce après chaque mise à jour APEX.

Avec le démarrage validé de la VM protégée, le service de compilation n'exécute que du code validé. Le code peut donc déterminer de n'accepter que les entrées qui répondent à certaines conditions, par exemple, n'accepter un fichier d'entrée que si son nom et le récapitulatif 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 d'entrée et les paramètres sont supposés provenir d'un client non approuvé et doivent être vérifiés avant d'être traités.

L'intégrité des fichiers d'entrée/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 validé avant d'être utilisé à 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. Avec le hachage racine fiable, 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, l'intégrité est maintenue avec le même format d'arborescence fs-verity lors de la génération, mais peut être mise à jour de manière dynamique. 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 les fichiers de sortie par signature.