Cas d'utilisation

Ce document contient des cas d'utilisation courants pour AVF.

Compilation isolée

En tant qu'enclave logicielle sécurisée, une 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 du bootclasspath et du serveur système (déclenchés par une mise à jour APEX) du démarrage précoce à 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 fidèlement les entrées vérifiées et de produire la sortie de manière isolée ; Android, en tant que client non fiable, ne peut modifier la sortie de la compilation que de provoquer son échec (lorsqu'Android revient à la compilation au démarrage).

Le service de compilation de la VM génère une signature uniquement s'il n'y a pas d'erreur pendant toute la compilation. Android peut récupérer la clé publique de la VM pour vérifier la 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 montés sur la VM, en plus d'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 machine virtuelle est démarrée au démarrage anticipé après chaque mise à jour APEX.

Avec le démarrage vérifié de Protected VM, le service de compilation exécute uniquement du code vérifié. Le code peut donc décider d'accepter uniquement les entrées qui satisfont à certaines conditions, par exemple, accepter un fichier d'entrée uniquement lorsque son nom et le résumé fs-verity sont définis dans une liste autorisée.

Toutes les API exposées depuis 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 et doivent être vérifiés et examinés avant d'être traités.

L'intégrité des fichiers d'entrée/sortie est vérifiée par la VM, avec les fichiers 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 utilisation à l'aide de l'algorithme fs-verity . Pour qu'un fichier d'entrée devienne 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 approuvé, un attaquant ne peut pas falsifier l'entrée sans être détecté.
• L'intégrité du fichier de sortie doit être conservée dans la VM. Même si un fichier de sortie est stocké sur Android, lors de la génération, l'intégrité est maintenue avec le même format d'arborescence fs-verity mais peut être mise à jour dynamiquement. Le fichier de sortie final peut être identifié grâce au hachage racine, qui est isolé dans la VM. Le service de la VM protège les fichiers de sortie par signature.