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 machine virtuelle 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 bootclasspath et des fichiers JAR 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 l'entrée vérifiée et de produire la sortie de manière isolée ; Android en tant que client non approuvé ne peut pas modifier la sortie de la compilation autrement que par 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 machine virtuelle pour la vérification de 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 le débogage.

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

Avec le démarrage vérifié de Protected VM, le service de compilation n'exécute que du code vérifié. 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 résumé fs-verity sont définis dans une liste blanche.

Toutes les API exposées de la machine virtuelle sont des surfaces d'attaque. Tous les fichiers et paramètres d'entrée sont supposés provenir d'un client non approuvé et doivent être vérifiés et approuvés avant le traitement.

L'intégrité des fichiers d'entrée/sortie est vérifiée par la machine virtuelle, 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 de confiance, un attaquant ne peut pas falsifier l'entrée sans être détecté.
• L'intégrité du fichier de sortie doit être maintenue dans la machine virtuelle. 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é avec le hachage racine, qui est isolé dans la VM. Le service de la machine virtuelle protège les fichiers de sortie par signature.