Sécurité

Pour empêcher l'exécution de charges utiles arbitraires dans une pVM, Android Virtualization Framework (AVF) utilise une approche de sécurité en couches dans laquelle chaque couche ajoute des applications supplémentaires. Voici une liste des couches de sécurité AVF :

  • Android garantit que seules les applications disposant d'autorisations pVM sont autorisées à créer ou à inspecter des pVM.

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

  • pVM fournit une défense en profondeur, comme avec SELinux , pour les charges utiles exécutées dans le pVM. La défense en profondeur interdit les données de mappage comme exécutables ( neverallow execmem ) et garantit que W^X est valable pour tous les types de fichiers.

Modèle de sécurité

Confidentialité, intégrité et disponibilité (triade CIA), constituent un modèle conçu pour guider les politiques de sécurité de l'information :

  • La confidentialité est un ensemble de règles qui limitent l'accès à l'information.
  • L'intégrité est l'assurance que les informations sont fiables et exactes.
  • La disponibilité est une garantie d'un accès fiable à l'information 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 des pages de mémoire physique individuelles et toutes les demandes des propriétaires pour que les pages soient partagées. pKVM garantit que seules les pVM autorisées (hôte et invités) ont la page donnée mappée dans leurs tables de pages de l'étape 2 contrôlées par l'hyperviseur. Cette architecture maintient que le contenu de la mémoire appartenant à une pVM reste privé à moins que le propriétaire ne le partage explicitement avec une autre pVM.

Les restrictions relatives au 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 des pVM, à savoir les appareils et services compatibles DMA s'exécutant dans des couches plus privilégiées . Les fournisseurs de systèmes sur puce (SoC) doivent satisfaire à un nouvel ensemble d'exigences avant de pouvoir prendre en charge pKVM. Dans le cas contraire, la confidentialité ne peut être assurée.

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

  • Modifier la mémoire de chacun sans consentement.
  • Influencez-vous mutuellement sur l'état du processeur.

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

Ces principes ne sont pas différents de l'isolation des processus proposée par Linux où l'accès aux pages mémoire est contrôlé avec des tables de pages de l'étape 1 et le contexte du noyau change entre les processus. Cependant, la partie EL2 de pKVM, qui applique ces propriétés, a environ la moitié de la surface d'attaque par rapport à l'ensemble du noyau Linux (environ 10 000 contre 20 millions de lignes de code) et offre donc une plus grande assurance pour les cas d'utilisation trop sensibles pour s'y fier. sur l'isolement des processus.

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

Le reste de cette page aborde les garanties de confidentialité et d’intégrité qu’offre 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 mutuellement méfiants. Ces propriétés sont valables en cas de compromission au sein d'une pVM, y compris l'hôte. Les hyperviseurs alternatifs conformes à 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, à moins qu'elle ne soit explicitement partagée par le propriétaire de la page. Cette règle inclut la pVM hôte et s'applique à la fois 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 du micrologiciel pVM d'un démarrage de périphérique est effacée avant que le chargeur de démarrage du système d'exploitation ne s'exécute lors du démarrage suivant du périphérique.

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

  • Le micrologiciel pVM 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é du instance.img est compromise.

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

Système d'exploitation invité

Microdroid est un exemple de système d'exploitation exécuté dans une pVM. Microdroid se compose d'un chargeur de démarrage basé sur U-boot, de GKI, d'un sous-ensemble de l'espace utilisateur Android et d'un lanceur de charge utile. Ces propriétés sont valables en cas de compromission au sein d'une pVM, y compris l'hôte. Les systèmes d'exploitation alternatifs exécutés dans une pVM devraient fournir des propriétés similaires.

  • Microdroid ne démarrera pas si boot.img , super.img , vbmeta.img ou vbmeta\_system.img ne peut pas être vérifié.

  • Microdroid ne démarrera pas si la vérification APK échoue.

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

  • Microdroid ne démarrera pas si l'un des APEX échoue à la vérification.

  • Microdroid ne démarrera pas (ou démarrera avec un état initial propre) si le instance.img est modifié en dehors de la pVM 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 provoque une erreur d'E/S du côté de la pVM.

  • Les BCC et CDI fournis à une instance pVM ne peuvent être dérivés que par cette instance particulière.

  • Les écritures sur un volume de stockage chiffré sont confidentielles, mais il n'existe aucune protection contre la restauration 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 un déchet pour Microdroid, plutôt que d'être détecté explicitement comme une erreur d'E/S.

Android

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

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

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

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

  • 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 pVM, la disponibilité fait référence au fait que l'hôte alloue suffisamment de ressources aux invités afin que ceux-ci puissent effectuer les tâches pour lesquelles ils sont conçus.

Les responsabilités de l'hôte incluent la planification des processeurs virtuels du pVM. KVM, contrairement aux hyperviseurs conventionnels de type 1 (tels que Xen), prend la décision 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 informatique sécurisée (TCB) et permet à l'hôte de prendre des décisions de planification plus éclairées pour optimiser les performances. Cependant, un hôte malveillant peut choisir de ne jamais programmer 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 responsable de la planification. Des efforts sont déployés pour garantir que le transfert des interruptions invitées n'entraîne qu'un déni de service (interruptions trop peu nombreuses, trop nombreuses ou mal acheminées).

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

Bien que pKVM n'offre pas de disponibilité aux invités, sa conception protège la disponibilité de l'hôte contre les invités malveillants, car l'hôte peut toujours préempter ou mettre fin à 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 aléatoirement un sel secret pour la pVM et en extrayant des détails, tels que les clés publiques de vérification et les hachages, des images chargées. Ces informations sont utilisées pour vérifier les démarrages ultérieurs de l'instance pVM et garantir que les secrets de l'instance sont divulgués uniquement aux images qui réussissent la vérification. Ce processus se produit à chaque étape de chargement au sein du pVM : micrologiciel pVM, pVM ABL, Microdroid, etc.

DICE fournit à chaque étape de chargement une paire de clés d'attestation dont la partie publique est certifiée dans l'entrée BCC de cette étape. Cette paire de clés peut changer entre les démarrages, de sorte qu'un secret de scellement est également dérivé, 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 machine virtuelle et ne doit donc pas être utilisé directement. Au lieu de cela, les clés de scellement doivent être dérivées du secret de scellement et le secret de scellement doit être détruit le plus tôt possible.

Chaque étape transmet un objet CBOR codé de manière déterministe à l’étape suivante. Cet objet contient des secrets et le BCC, qui contient des informations d'état accumulées, par exemple si la dernière étape a été chargée en toute sécurité.

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 des utilisateurs 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 déverrouillé, le propriétaire de l'appareil est libre de reflasher les partitions qui sont généralement protégées par un démarrage vérifié, y compris les partitions contenant l'implémentation pKVM. Par conséquent, pKVM sur un appareil déverrouillé ne sera pas fiable pour maintenir le modèle de sécurité.

Les parties distantes peuvent observer cet état potentiellement non sécurisé en inspectant l' état de démarrage vérifié du périphérique dans un certificat d'attestation de clé.