Google is committed to advancing racial equity for Black communities. See how.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Vérification du démarrage

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 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 tout le 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 (comme 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'arborescence 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 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 entre dans un état d'erreur. Pour plus de détails, consultez 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. Fondamentalement, 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 Démarrage vérifié Android pour plus de détails.

Protection anti-retour

Même avec un processus de mise à jour complètement sécurisé, il est possible pour un exploit de noyau Android non persistant d'installer manuellement une version plus ancienne et plus vulnérable d'Android, de redémarrer dans la version vulnérable, puis d'utiliser cette version d'Android pour installer un exploit persistant. À partir de là, l'attaquant est définitivement propriétaire de l'appareil et peut tout faire, y compris la désactivation des mises à jour.

La protection contre cette classe d'attaques s'appelle Rollback Protection . La protection anti-retour 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 sur une base par partition.

Pour plus de détails sur la manière dont AVB gère les protections anti-retour, consultez AVB README .

Gestion des erreurs de vérification

La vérification peut échouer au moment du 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 moment du 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 le périphérique utilise dm-verity, il doit être configuré en mode restart . En mode restart , si une erreur de vérification est rencontrée, le périphérique 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 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 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é) ou que l'utilisateur puisse extraire 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 nouveau système d'exploitation installé et repasse en mode restart .