Sécurité

Pour empêcher l'exécution de charges utiles arbitraires dans une pVM, le framework de virtualisation Android (AVF) utilise une approche de sécurité multicouche dans laquelle chaque couche ajoute des mesures d'application supplémentaires. Voici une liste des couches de sécurité AVF:

  • Android s'assure que seules les applications disposant d'autorisations de VM parallèles sont autorisées à en créer ou à en inspecter.

  • Bootloader : le bootloader garantit que seules les images de pVM signées par Google ou les fournisseurs d'appareils sont autorisées à démarrer et respecte la procédure de démarrage validé Android. Cette architecture implique que les applications exécutant des pVM ne peuvent pas regrouper leurs propres noyaux.

  • La pVM fournit une défense en profondeur, comme avec SELinux, pour les charges utiles exécutées dans la pVM. La défense en profondeur interdit de mapper des données en tant qu'exécutables (neverallow execmem) et garantit que W^X s'applique à tous les types de fichiers.

Modèle de sécurité

La confidentialité, l'intégrité et la disponibilité (triade CIA) constituent un modèle conçu pour guider les règles de sécurité des informations:

  • La confidentialité est un ensemble de règles qui limitent l'accès aux informations.
  • L'intégrité garantit que les informations sont fiables et exactes.
  • La disponibilité garantit un accès fiable aux informations par les entités autorisées.

Confidentialité et intégrité

La confidentialité découle des propriétés d'isolation de la mémoire appliquées par l'hyperviseur pKVM. pKVM suit la propriété de la mémoire de chaque page de mémoire physique et toute demande de partage de pages de la part des propriétaires. pKVM s'assure que seules les pVM (hôte et invités) autorisées ont la page donnée mappée dans leurs tables de pages d'étape 2 contrôlées par l'hyperviseur. Cette architecture affirme que le contenu de la mémoire appartenant à une pVM reste privé, sauf si le propriétaire le partage explicitement avec une autre pVM.

Les restrictions concernant le maintien de la confidentialité s'étendent également à toutes les entités du système qui effectuent des accès à la mémoire pour le compte de VM préemptives, à savoir les appareils compatibles avec la loi DMA et les services s'exécutant dans des couches plus privilégiées. Les fournisseurs de systèmes sur puce (SoC) doivent répondre à un nouvel ensemble d'exigences avant de pouvoir prendre en charge pKVM. Sinon, la confidentialité ne peut pas être assurée.

L'intégrité s'applique aux données en mémoire et au calcul. Les pVM ne peuvent pas:

  • Modifier la mémoire de l'autre personne sans obtenir son consentement
  • Influer sur l'état du processeur de l'autre.

Ces exigences sont appliquées par l'hyperviseur. Toutefois, des problèmes d'intégrité des données surviennent également avec le stockage virtuel des données lorsque d'autres solutions, telles que dm-verity ou AuthFS, doivent être appliquées.

Ces principes ne diffèrent pas de l'isolation de processus proposée par Linux, où l'accès aux pages de mémoire est contrôlé par des tables de pages d'étape 1 et les changements de contexte du noyau entre les processus. Cependant, la partie EL2 de pKVM, qui applique ces propriétés, présente une surface d'attaque trois ordres de grandeur en moins par rapport à l'ensemble du noyau Linux (environ 10 000 contre 20 millions de lignes de code) et offre donc une garantie plus solide pour les cas d'utilisation trop sensibles pour dépendre de l'isolation de processus.

Compte tenu de sa taille, pKVM se prête à une vérification formelle. Nous soutenons activement la recherche universitaire, qui vise à prouver officiellement ces propriétés sur le binaire pKVM réel.

Le reste de cette page traite des garanties de confidentialité et d'intégrité fournies par chaque composant d'un pKVM.

Hyperviseur

pKVM est un hyperviseur basé sur KVM qui isole les pVM et Android dans des environnements d'exécution mutuellement non approuvés. Ces propriétés sont conservées en cas de compromission dans n'importe quelle pVM, y compris l'hôte. Les hyperviseurs alternatifs conformes à l'AVF doivent fournir des propriétés similaires.

  • Une pVM ne peut pas accéder à une page appartenant à une autre entité, telle qu'une pVM ou un hyperviseur, sauf si le propriétaire de la page l'a explicitement partagée. Cette règle inclut la pVM hôte et s'applique aux accès du processeur et de la zone de marché désignée.

  • Avant qu'une page utilisée par une pVM ne soit renvoyée à l'hôte, par exemple lorsque la pVM est détruite, elle est effacée.

  • La mémoire de toutes les pVM et le micrologiciel de la pVM à partir d'un démarrage de l'appareil sont effacés avant que le bootloader de l'OS ne s'exécute lors du démarrage de l'appareil suivant.

  • Lorsqu'un débogueur matériel, tel que SJTAG, est associé, une pVM ne peut pas accéder à ses clés précédemment créées.

  • Le micrologiciel de la pVM ne démarre pas s'il ne parvient pas à valider l'image initiale.

  • Le micrologiciel de la pVM ne démarre pas si l'intégrité de instance.img est compromise.

  • La chaîne de certificats DICE et les identifiants d'appareils composés (CDI) fournis à une instance de pVM ne peuvent être dérivés que par cette instance particulière.

OS invité

Microdroid est un exemple d'OS exécuté dans une pVM. Microdroid se compose d'un bootloader basé sur le démarrage U, GKI, d'un sous-ensemble de l'espace utilisateur Android et d'un lanceur de charge utile. Ces propriétés restent valables en cas de compromission au sein de n'importe quelle VM préemptive, y compris l'hôte. Les autres systèmes d'exploitation exécutés sur une pVM doivent fournir des propriétés similaires.

  • Microdroid ne démarre pas si boot.img, super.img, vbmeta.img ou vbmeta\_system.img ne peuvent pas être validés.

  • Microdroid ne démarre pas si la validation de l'APK échoue.

  • La même instance Microdroid ne démarrera pas, même si l'APK a été mis à jour.

  • Microdroid ne démarre pas si l'un des APEX échoue à la validation.

  • Microdroid ne démarre pas (ou démarre avec un état initial propre) si instance.img est modifié en dehors de la pVM invitée.

  • Microdroid fournit une attestation à la chaîne de démarrage.

  • Toute modification (non signée) apportée aux images de disque partagées avec la pVM invitée entraîne une erreur d'E/S côté pVM.

  • La chaîne de certificats DICE et les IDC fournis à une instance pVM ne peuvent être dérivés que de cette instance particulière.

  • Les écritures sur un volume de stockage chiffré sont confidentielles. Toutefois, il n'existe aucune protection de rollback au niveau de la granularité d'un bloc de chiffrement. De plus, en raison d'autres falsifications externes arbitraires d'un bloc de données, celui-ci apparaît comme un élément de mauvaise qualité pour Microdroid, au lieu d'être détecté explicitement comme une erreur d'E/S.

Android

Il s'agit de propriétés gérées par Android en tant qu'hôte, mais qui ne sont pas vraies en cas de compromission de l'hôte:

  • Une pVM invitée ne peut pas interagir directement avec d'autres pVM invitées (par exemple, pour établir une connexion vsock).

  • Seul le VirtualizationService de la pVM hôte peut créer un canal de communication vers une pVM.

  • Seules les applications signées avec la clé de plate-forme peuvent demander l'autorisation de créer, de posséder ou d'interagir avec des pVM.

  • L'identifiant, appelé identifiant de contexte (CID), utilisé pour configurer les connexions vsock entre l'hôte et la VM préemptive n'est pas réutilisé lorsque la pVM hôte est en cours d'exécution. Par exemple, vous ne pouvez pas remplacer une pVM en cours d'exécution par une autre.

Disponibilité

Dans le contexte des pVM, la disponibilité fait référence à l'allocation par l'hôte de ressources suffisantes aux invités afin qu'ils puissent effectuer les tâches pour lesquelles ils sont conçus.

L'hôte est chargé de planifier les processeurs virtuels de la pVM. Contrairement aux hyperviseurs de type 1 classiques (tels que Xen), KVM prend la décision de conception explicite de déléguer la planification des charges de travail au noyau hôte. Compte tenu de la taille et de la complexité des planificateurs actuels, cette décision de conception réduit considérablement la taille de la base de calcul sécurisée (TCB) et permet à l'hôte de prendre des décisions de planification plus éclairées pour optimiser les performances. Toutefois, un hôte malveillant peut choisir de ne jamais planifier d'invité.

De même, pKVM délègue également la gestion des interruptions physiques au noyau hôte pour réduire la complexité de l'hyperviseur et laisser l'hôte se charger de la planification. Des efforts sont faits pour s'assurer que le transfert des interruptions de l'invité se traduit uniquement par un déni de service (trop peu, trop d'interruptions ou mal acheminée).

Enfin, le processus de surveillance de la machine virtuelle (VMM) de l'hôte est chargé d'allouer de la mémoire et de fournir des appareils virtuels, tels qu'une carte réseau. Un VMM malveillant peut retenir des ressources de l'invité.

Bien que la pKVM ne fournisse pas de disponibilité aux invités, la conception protège la disponibilité de l'hôte contre les invités malveillants, car l'hôte peut toujours préempter ou arrêter un invité et récupérer ses ressources.

Démarrage sécurisé

Les données sont associées aux instances d'une pVM, et le démarrage sécurisé garantit que l'accès aux données d'une instance peut être contrôlé. Le premier démarrage d'une instance la provisionne en générant de manière aléatoire un salage secret pour la pVM et en extrayant des informations, telles que les clés publiques de vérification et les hachages, à partir des images chargées. Ces informations permettent de vérifier les démarrages ultérieurs de l'instance de VM préemptive et de s'assurer que les secrets de l'instance ne sont publiés que sur les images validées. Ce processus se produit pour chaque étape de chargement de la pVM: micrologiciel pVM, ABL pVM, Microdroid, etc.

DICE fournit à chaque étape de chargement une paire de clés d'attestation, dont la partie publique est certifiée dans le certificat DICE pour cette étape. Cette paire de clés peut changer d'un démarrage à l'autre. Par conséquent, un secret de fermeture est également dérivé. Il est stable pour l'instance de VM lors des redémarrages et, en tant que tel, adapté à la protection de l'état persistant. Le secret de scellement est très utile pour la VM. Il ne doit donc pas être utilisé directement. À la place, les clés de scellement doivent être dérivées du secret de scellement, et le secret de scellement doit être détruit dès que possible.

Chaque étape transmet un objet CBOR encodé de manière déterministe à l'étape suivante. Cet objet contient des secrets et la chaîne de certificats DICE, qui contient des informations d'état cumulées, par exemple si la dernière étape s'est chargée de manière sécurisée.

Appareils déverrouillés

Lorsqu'un appareil est déverrouillé avec fastboot oem unlock, les données utilisateur sont effacées. Ce processus protège les données utilisateur contre tout accès non autorisé. Les données privées d'une pVM sont également invalidées lors du déverrouillage de l'appareil.

Une fois l'appareil déverrouillé, le propriétaire peut flasher à nouveau les partitions habituellement protégées par le démarrage validé, y compris les partitions contenant l'implémentation pKVM. Par conséquent, sur un appareil déverrouillé, le pKVM n'est pas considéré comme fiable pour maintenir le modèle de sécurité.

Les tiers à distance peuvent observer cet état potentiellement non sécurisé en inspectant l'état de démarrage validé de l'appareil dans un certificat d'attestation de clé.