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é en couches dans laquelle chaque couche ajoute des mesures d'application supplémentaires. Voici la liste des couches de sécurité AVF:

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

  • 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 limite 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 maintient 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 visant à préserver la confidentialité s'étendent également à toutes les entités du système qui effectuent des accès à la mémoire au nom des pVM, à savoir les appareils compatibles avec DMA et les services exécutés dans des couches plus privilégiées. Les fournisseurs de SoC (System-on-Chip) doivent répondre à un nouvel ensemble d'exigences avant de pouvoir prendre en charge le 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 sans son autorisation ;
  • 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 de données virtuel lorsque d'autres solutions doivent être appliquées, telles que dm-verity ou AuthFS.

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 par les changements de contexte du noyau entre les processus. Toutefois, la partie EL2 de pKVM, qui applique ces propriétés, présente une surface d'attaque trois ordres de grandeur inférieure à celle de l'intégralité du kernel Linux (environ 10 000 lignes de code contre 20 millions) et offre donc une assurance plus forte aux cas d'utilisation trop sensibles pour s'appuyer sur l'isolation des processus.

Compte tenu de sa taille, pKVM se prête à la validation formelle. Nous soutenons activement la recherche universitaire, qui vise à prouver formellement 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 CPU et DMA.

  • 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 peut pas vérifier 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 U-boot, GKI, d'un sous-ensemble de l'espace utilisateur Android et d'un lanceur de charge utile. Ces propriétés sont conservées en cas de compromission dans n'importe quelle pVM, y compris l'hôte. Les autres OS exécutés dans 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 CDIs fournis à une instance de pVM ne peuvent être dérivés que par 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, toute autre falsification externe arbitraire d'un bloc de données fait apparaître ce bloc comme des données indésirables pour Microdroid, plutôt que 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 du pVM hôte peut créer un canal de communication vers un 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 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 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 en charge de la planification. Des efforts sont faits pour s'assurer que le transfert des interruptions invitées ne se traduit que par un déni de service (interruptions trop peu nombreuses, trop nombreuses ou mal acheminées).

Enfin, le processus de moniteur de machine virtuelle (VMM) de l'hôte est chargé d'allouer de la mémoire et de fournir des périphériques 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 sel secret pour la pVM et en extrayant des détails, tels que des clés publiques de validation et des hachages, à partir des images chargées. Ces informations sont utilisées pour valider les démarrages ultérieurs de l'instance de pVM et s'assurer que les secrets de l'instance ne sont publiés que pour les images qui passent la validation. Ce processus se produit pour chaque étape de chargement dans la pVM: micrologiciel de la pVM, ABL de la 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 entre les démarrages. Un secret de scellement est donc également dérivé, qui est stable pour l'instance de VM lors des redémarrages et, par conséquent, convient à la protection de l'état persistant. Le secret de scellement est très important 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 lorsqu'un déverrouillage de l'appareil se produit.

Une fois l'appareil déverrouillé, le propriétaire peut flasher à nouveau les partitions qui sont généralement protégées par le démarrage validé, y compris les partitions contenant l'implémentation pKVM. Par conséquent, le pKVM sur un appareil déverrouillé ne sera pas approuvé pour respecter le modèle de sécurité.

Les parties distantes 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é.