Le démarrage vérifié nécessite une vérification cryptographique de tout le code exécutable et des données faisant partie de la version Android en cours de démarrage avant de l'utiliser. 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é du contenu en mémoire, puis en calculant son 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 plus de détails, consultez Flux de démarrage .
Les partitions plus grandes qui ne rentrent pas dans la mémoire (telles que les systèmes de fichiers) peuvent utiliser une arborescence de hachage où la vérification est un processus continu se déroulant au fur et à mesure que les données sont chargées en mémoire. Dans ce cas, le hachage racine de l'arbre de hachage est calculé pendant l'exécution et vérifié par rapport à la valeur de hachage racine attendue . Android inclut le pilote dm-verity pour vérifier les partitions plus grandes. 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 entre dans un état d'erreur. Pour plus de détails, consultez corruption dm-verity .
Les hachages attendus sont généralement stockés soit à la fin, soit au début de chaque partition vérifiée, dans une partition dédiée, ou les deux. Surtout, ces hachages sont signés (directement ou indirectement) par la racine de confiance. À titre d'exemple, l'implémentation AVB prend en charge les deux approches, voir Android Verified Boot pour plus de détails.
Protection contre la restauration
Même avec un processus de mise à jour entièrement sécurisé, il est possible qu'un exploit non persistant du noyau Android installe manuellement une version plus ancienne et plus vulnérable d'Android, redémarre dans la version vulnérable, puis utilise cette version d'Android pour installer un exploit persistant. À partir de là, l’attaquant possède en permanence l’appareil et peut tout faire, y compris désactiver les mises à jour.
La protection contre cette classe d'attaques est appelée Rollback Protection . La protection contre la restauration est généralement mise en œuvre en utilisant un stockage inviolable pour enregistrer la version la plus récente d'Android et en refusant de démarrer Android si elle est inférieure à la version enregistrée. Les versions sont généralement suivies par partition.
Pour plus de détails sur la façon dont AVB gère les protections contre la restauration, consultez le fichier README AVB.
Gestion des erreurs de vérification
La vérification peut échouer soit au moment du démarrage (par exemple, si le hachage calculé sur la partition boot ne correspond pas au hachage attendu), soit au moment de l'exécution (par exemple, si dm-verity rencontre une erreur de vérification sur la partition system ). Si la vérification échoue au moment du démarrage, le périphérique ne peut pas démarrer et l'utilisateur final doit suivre les étapes pour récupérer le périphérique.
Si la vérification échoue au moment 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 vérification est rencontrée, l'appareil est immédiatement redémarré avec un indicateur spécifique défini pour en indiquer la raison. Le chargeur de démarrage doit remarquer cet indicateur et basculer dm-verity pour utiliser le mode Erreur d'E/S ( eio ) et rester dans ce mode jusqu'à ce qu'une nouvelle mise à jour soit 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 peut ne pas fonctionner correctement. L'écran s'affiche jusqu'à ce que l'utilisateur le rejette. En mode eio , le pilote dm-verity ne redémarrera pas le périphérique si une erreur de vérification est rencontrée. Au lieu de cela, une erreur EIO est renvoyée et l'application doit gérer l'erreur.
L'intention est que soit le programme de mise à jour du système s'exécute (afin qu'un nouveau système d'exploitation sans erreur de corruption puisse être installé), soit que l'utilisateur puisse récupérer autant de données que possible de l'appareil. Une fois le nouveau système d'exploitation installé, le chargeur de démarrage remarque le système d'exploitation nouvellement installé et repasse en mode restart .