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 garantit que seules les applications disposant d'autorisations liées aux VM préemptives sont autorisées à créer ou à inspecter des VM préemptives.

• 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 VM préemptives ne peuvent pas regrouper leurs propres noyaux.

• La pVM offre une défense en profondeur, par exemple avec SELinux, pour les charges utiles exécutées dans la pVM. La défense en profondeur interdit les données de mappage en tant qu'exécutables (neverallow execmem) et garantit que W^X est conservé pour tous les types de fichiers.

  Remarque :La défense en profondeur n'empêche pas la communication avec une VM préemptive, ce qui peut être obtenu en fournissant un accès à un handle IBinder de pVM.

Modèle de sécurité

Confidentialité, intégrité et disponibilité (triade CIA), constituent un modèle conçu pour guider les stratégies de sécurité des informations:

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

Remarque :pKVM est conçu pour préserver la confidentialité et l'intégrité (pas la disponibilité) des invités. Ces principes influencent les décisions de conception qui couvrent tous les aspects de l'architecture, de l'hyperviseur aux composants de l'espace utilisateur.

Important :pKVM n'offre pas de protection efficace contre les attaques sur des niveaux d'exception plus privilégiés, tels que le monde sécurisé (EL3 et S-ELx). Il ne protège pas contre les fournisseurs OEM et SoC malveillants ni contre les attaques contre le matériel lui-même. L'équipe Android collabore avec l'écosystème des fournisseurs pour appliquer les bonnes pratiques et réduire le risque de telles attaques.

Important :pKVM ne s'efforce pas de se protéger contre les attaques de canaux secondaires, au-delà de la correction des défauts matériels et logiciels classiques, comme des solutions pour les errata de processeur connues. Android investit dans des technologies avancées qui vérifient officiellement les propriétés d'isolation des propriétés de l'hyperviseur et de l'architecture matérielle.

Confidentialité et intégrité

La confidentialité découle des propriétés d'isolation de mémoire appliquées par l'hyperviseur pKVM. pKVM suit la propriété de la mémoire des pages de mémoire physique individuelles et toutes les demandes des propriétaires de pages à partager. pKVM garantit que seules les pVM autorisées (hôte et invités) ont la page donnée mappée dans leurs tables de page de l'étape 2 qui sont contrôlées par l'hyperviseur. Cette architecture préserve que le contenu de la mémoire appartenant à une VM préemptive reste privé, sauf si le propriétaire le partage explicitement avec une autre VM préemptive.

Les restrictions concernant le maintien de la confidentialité s'appliquent é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 fournie.

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

• Modifier la mémoire de l'autre personne sans obtenir son consentement
• Influencez mutuellement l'état du processeur de chacun.

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 sont semblables à l'isolation de processus proposée par Linux, où l'accès aux pages de mémoire est contrôlé avec les tables de pages de l'étape 1 et le changement 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 autour d'un pKVM.

Hyperviseur

pKVM est un hyperviseur basé sur KVM qui isole les pVM et Android dans des environnements d'exécution dont la confiance est partagée. 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 hyperviseurs alternatifs conformes à la norme 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 elle est explicitement partagée par son propriétaire. 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 lorsqu'elle est détruite, elle est effacée.

• La mémoire de toutes les VM préemptives et le micrologiciel des VM préemptives du démarrage d'un appareil est effacée avant que le bootloader de l'OS ne s'exécute lors du démarrage suivant de l'appareil.

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

• Le micrologiciel de la VM préemptive ne démarre pas s'il ne peut pas vérifier l'image initiale.

• Le micrologiciel 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 VM préemptive ne peuvent être dérivés que de cette instance particulière.

OS invité

Microdroid est un exemple d'OS s'exécutant 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 du fichier APK échoue.

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

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

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

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

• Toute modification (non signée) des images 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, mais il n'existe pas de protection contre le rollback du point de vue 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 VM invitées (pour établir une connexion vsock, par exemple).

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

  Remarque :La chaîne établie peut être transmise à d'autres utilisateurs.

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

• L'identifiant, appelé identifiant de contexte (CID), utilisé lors de la configuration des connexions vsock entre l'hôte et la pVM 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 VM préemptives, la disponibilité fait référence à l'hôte qui alloue suffisamment de ressources aux invités pour qu'ils puissent effectuer les tâches pour lesquelles ils sont conçus.

Les responsabilités de l'hôte incluent la planification des 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 de confiance (TCB) et permet à l'hôte de prendre des décisions de planification plus éclairées afin d'optimiser les performances. Cependant, un hôte malveillant peut choisir de ne jamais planifier un 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 dissimuler des ressources à l'invité.

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

Démarrage sécurisé

Les données sont lié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 par 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 précieux 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 celui-ci doit être détruit le plus tôt possible.

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

Appareils débloqué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 les accès non autorisés. Les données privées d'une pVM sont également invalidées lors du déverrouillage d'un appareil.

Une fois déverrouillé, le propriétaire de l'appareil est libre de reflasher les partitions généralement 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é.