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 – 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 – Le 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é

La confidentialité, l'intégrité et la disponibilité, également connue sous le nom de triade CIA, sont 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.

Notez que pKVM a été conçu pour maintenir la confidentialité et l'intégrité, mais pas la disponibilité, des invités. Ces principes influencent les décisions de conception couvrant tous les aspects de l'architecture, de l'hyperviseur aux composants de l'espace utilisateur.

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 SoC doivent satisfaire à un nouvel ensemble d'exigences avant de pouvoir prendre en charge pKVM, sinon la confidentialité ne pourra pas être assurée.

L'intégrité s'applique à la fois aux données en mémoire et aux calculs :

  • Les pVM ne peuvent pas modifier la mémoire de chacun sans consentement.
  • Les pVM ne peuvent pas influencer l'état du processeur de chacun.

Ces exigences sont appliquées par l'hyperviseur. Mais des problèmes concernant l'intégrité des données se posent également avec le stockage de données virtuel où 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.

La suite de ce document couvre les garanties de confidentialité et d’intégrité qu’apporte 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, établir une connexion vsock avec) d'autres pVM invitées.
  • Seul le VirtualizationService dans la pVM hôte peut créer un canal de communication vers une pVM (Remarque : il peut transmettre le canal établi à d'autres).
  • 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é pendant l'exécution de la pVM hôte. Par exemple, remplacer une pVM en cours d’exécution par une autre n’est pas possible.

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 ont été conçus.

Les responsabilités de l'hôte incluent la planification des processeurs virtuels du pVM. KVM, contrairement aux hyperviseurs traditionnels 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 du périphérique 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é.