Verified Boot exige la validation cryptographique de l'ensemble du code exécutable et des données qui font partie de la version d'Android en cours de démarrage avant leur utilisation. Cela inclut le noyau (chargé à partir de la partition boot), l'arborescence des périphériques (chargée à partir de la partition dtbo), la partition system, la partition vendor, etc.
Les petites partitions, telles que boot et dtbo, qui ne sont lues qu'une seule fois, sont généralement vérifiées en chargeant l'intégralité de leur contenu en mémoire, puis en calculant leur hachage. Cette valeur de hachage calculée est ensuite comparée à la valeur de hachage attendue. Si la valeur ne correspond pas, Android ne se chargera pas.
Pour en savoir plus, consultez Flux de démarrage.
Les partitions plus volumineuses qui ne tiennent pas dans la mémoire (comme les systèmes de fichiers) peuvent utiliser un arbre de hachage où la validation est un processus continu qui se produit lorsque les données sont chargées en mémoire. Dans ce cas, le hachage racine de l'arbre de hachage est calculé lors de l'exécution et comparé à la valeur de hachage racine attendue. Android inclut le pilote dm-verity pour valider les partitions plus volumineuses. Si, à un moment donné, le hachage racine calculé ne correspond pas à la valeur de hachage racine attendue, les données ne sont pas utilisées et Android passe à un état d'erreur. Pour en savoir plus, consultez Corruption de dm-verity.
Les hachages attendus sont généralement stockés à la fin ou au début de chaque partition validée, dans une partition dédiée, ou les deux. Il est essentiel de noter que ces hachages sont signés (directement ou indirectement) par la racine de confiance. Par exemple, l'implémentation AVB prend en charge les deux approches. Pour en savoir plus, consultez Démarrage validé Android.
Protection contre le rollback
Même avec un processus de mise à jour entièrement sécurisé, il est possible qu'une exploitation non persistante du noyau Android installe manuellement une version plus ancienne et plus vulnérable d'Android, redémarre sur cette version vulnérable, puis utilise cette version d'Android pour installer une exploitation persistante. L'attaquant devient alors propriétaire de l'appareil de manière permanente et peut faire ce qu'il veut, y compris désactiver les mises à jour.
La protection contre cette catégorie d'attaques est appelée protection contre la restauration. La protection contre le rollback est généralement implémentée à l'aide d'un stockage inviolable pour enregistrer la version la plus récente d'Android et en refusant de démarrer Android si sa version est inférieure à celle enregistrée. Les versions sont généralement suivies par partition.
Pour en savoir plus sur la façon dont AVB gère les protections contre le rollback, consultez le fichier README d'AVB.
Gérer les erreurs de validation
La validation peut échouer au moment du démarrage (par exemple, si le hachage calculé sur la partition boot ne correspond pas au hachage attendu) ou au moment de l'exécution (par exemple, si dm-verity rencontre une erreur de validation sur la partition system). Si la validation échoue au moment du démarrage, l'appareil ne peut pas démarrer et l'utilisateur final doit suivre des étapes pour le récupérer.
Si la validation échoue au moment de l'exécution, le flux est un peu plus complexe. Si l'appareil utilise dm-verity, il doit être configuré en mode restart. En mode restart, si une erreur de validation est détectée, l'appareil est immédiatement redémarré avec un indicateur spécifique défini pour indiquer la raison. Le bootloader doit remarquer cet indicateur et passer dm-verity en mode Erreur d'E/S (eio), et rester dans ce mode jusqu'à ce qu'une nouvelle mise à jour ait été installée.
Lors du démarrage en mode eio, l'appareil affiche un écran d'erreur informant l'utilisateur qu'une corruption a été détectée et que l'appareil risque de ne pas fonctionner correctement. L'écran s'affiche jusqu'à ce que l'utilisateur le ferme. En mode eio, le pilote dm-verity ne redémarre pas l'appareil en cas d'erreur de validation. Au lieu de cela, une erreur EIO est renvoyée et l'application doit gérer l'erreur.
L'objectif est que le programme de mise à jour du système s'exécute (afin qu'un nouvel OS sans erreurs de corruption puisse être installé) ou que l'utilisateur puisse récupérer le plus de données possible sur l'appareil. Une fois le nouvel OS installé, le chargeur de démarrage le détecte et repasse en mode restart.