Verified Boot nécessite de vérifier de manière cryptographique tout le code exécutable et toutes les données qui font partie de la version Android en cours de démarrage avant de les utiliser. Cela inclut le kernel (chargé à partir de la partition boot), l'arborescence de 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 charge pas.
Pour en savoir plus, consultez Flux de démarrage.
Les partitions plus volumineuses qui ne tiennent pas en mémoire (telles que les systèmes de fichiers) peuvent utiliser une arborescence de hachage où la vérification 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'arborescence de hachage est calculé lors de l'exécution et comparé à la valeur de hachage racine attendue. Android inclut le pilote dm-verity pour vérifier 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 dm-verity.
Les hachages attendus sont généralement stockés à la fin ou au début de chaque partition vérifiée, dans une partition dédiée, ou les deux. Il est essentiel que ces hachages soient signés (directement ou indirectement) par la racine de confiance. Par exemple, l'implémentation AVB est compatible avec les deux approches. Pour en savoir plus, consultez Démarrage vérifié 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 d'Android plus ancienne et plus vulnérable, redémarre dans la version vulnérable, puis utilise cette version d'Android pour installer une exploitation persistante. L'attaquant possède alors l'appareil de manière permanente et peut tout faire, y compris désactiver les mises à jour.
La protection contre cette classe d'attaques est appelée protection contre le rollback. 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 refuser de démarrer Android si elle est inférieure à la version 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 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 lors 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 lors de l'exécution, le flux est un peu plus compliqué. 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 chargeur de démarrage doit remarquer cet indicateur et passer dm-verity en mode d'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 si une erreur de validation est détectée. 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 nouveau système d'exploitation sans erreurs de corruption puisse être installé) ou que l'utilisateur puisse récupérer autant de données que possible sur l'appareil. Une fois le nouveau système d'exploitation installé, le chargeur de démarrage le détecte et repasse en mode restart.