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 son utilisation. Cela inclut le noyau (chargé à partir de la partition de 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 tiennent pas dans la mémoire (telles que les systèmes de fichiers) peuvent utiliser un arbre 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'arbre de hachage est calculé pendant l'exécution et est 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, voir dm-verity corruption .
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. 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 antiretour
Même avec un processus de mise à jour entièrement sécurisé, il est possible qu'un exploit de noyau Android non persistant 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 les annulations, consultez le README AVB .
Gérer les erreurs de vérification
La vérification peut échouer au démarrage (par exemple, si le hachage calculé sur la partition de boot ne correspond pas au hachage attendu) ou 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 démarrage, l'appareil ne peut pas démarrer et l'utilisateur final doit suivre les étapes pour récupérer l'appareil.
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 indiquer la raison. Le chargeur de démarrage doit remarquer cet indicateur et basculer dm-verity pour utiliser le mode d'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, mais une erreur EIO est renvoyée et l'application doit traiter 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 erreurs de corruption puisse être installé), soit l'utilisateur peut obtenir 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 de restart .