Tous les appareils lancés avec Android Pie (Android 9) doivent prendre en charge le démarrage vérifié (Android Verified Boot 2.0), qui permet une protection contre la restauration.
Tarte Android (Android 9) vient d'être mis en ligne aujourd'hui pour le Google Pixel, le Google Pixel 2 et Même le Téléphone essentiel. Nous en apprenons le plus possible sur la sortie des interviews (le Google Pixel 3 n'aura qu'une navigation gestuelle!), le Suppression du code AOSP, et enfin le Document de Définition de Compatibilité (CDD). Nous avons publié un article sur un nouvelle fonctionnalité pour les applications « lourdes » plus tôt dans la journée, mais nous avons découvert que Google avait modifié sa formulation concernant une fonctionnalité introduite dans Android Oreo: protection contre la restauration. La fonctionnalité est rendue possible par Démarrage vérifié Android 2.0 (également connu simplement sous le nom de Verified Boot), cependant, les OEM n'étaient pas tenus d'implémenter AVB 2.0 dans la version Oreo. Désormais, Google exige que tous les appareils lancés avec Android Pie prennent en charge le démarrage vérifié et, par extension, la protection contre la restauration.
Protection contre la restauration dans Android Oreo
L'essentiel de la fonctionnalité est qu'elle empêchera votre téléphone de démarrer s'il détecte que l'appareil a été rétrogradé. vers une version antérieure, désormais non approuvée, d'un logiciel qui a été jugée non sécurisée en raison d'un problème de sécurité vulnérabilité. Une explication légèrement plus technique est que la structure de données VBMeta, qui contient le hachage de la partition de démarrage et métadonnées hashtree pour les partitions système et fournisseur, utilise un index de restauration pour rejeter les images ayant une restauration plus ancienne indice.
Cette fonctionnalité est présente sur des appareils comme le Google Pixel 2, le Razer Phone et le OnePlus 6, mais n'est pas présente sur de nombreux autres appareils comme le Samsung Galaxy S9 (bien que Samsung propose sa propre forme de protection contre la restauration dans Knox.) Désormais, Google rend cette fonctionnalité obligatoire pour tout appareil lancé avec Android Pie.
Démarrage vérifié dans Android Pie
Selon le libellé mis à jour dans la section « Intégrité des appareils » du document de définition de compatibilité, les appareils lancés avec Android 9 doivent prendre en charge le démarrage vérifié.
9.10. Intégrité de l'appareil
Les exigences suivantes garantissent la transparence de l’état de l’intégrité de l’appareil. Implémentations d'appareils :
- [C-0-1] DOIT signaler correctement via la méthode de l'API système PersistentDataBlockManager.getFlashLockState() si l'état de son chargeur de démarrage permet le flashage de l'image système. L'état FLASH_LOCK_UNKNOWN est réservé aux implémentations d'appareils mises à niveau à partir d'une version antérieure d'Android pour lesquelles cette nouvelle méthode API système n'existait pas.
- [C-0-2] DOIT prendre en charge le démarrage vérifié pour l'intégrité du périphérique.
Si les implémentations d'appareils sont déjà lancées sans prendre en charge le démarrage vérifié sur une version antérieure d'Android et ne peuvent pas ajouter la prise en charge de cette fonctionnalité avec une mise à jour du logiciel système, ils PEUVENT être exemptés de la exigence.
...
- [C-1-10] DOIT mettre en œuvre une protection contre la restauration pour les partitions utilisées par Android (par exemple, démarrage, partitions système) et utiliser un stockage inviolable pour stocker les métadonnées utilisées pour déterminer le système d'exploitation minimum autorisé version.
- DEVRAIT implémenter une protection contre la restauration pour tout composant doté d'un micrologiciel persistant (par exemple, modem, appareil photo) et DEVRAIT utiliser un stockage inviolable pour stocker les métadonnées utilisées pour déterminer le minimum autorisé version.
Comme vous pouvez le voir dans les deux dernières séries de puces, il y a une mise en garde à noter. La protection contre la restauration est requise pour les partitions utilisées par Android (démarrage, système, fournisseur, etc.), mais pas pour les partitions avec un micrologiciel persistant (modem, appareil photo, etc.). C'est dans l'ancien ensemble de partitions que la plupart des failles de sécurité sont découvertes et corrigées. Il est donc agréable de voir que la protection de ces partitions est obligatoire. Cependant, il y a eu des exploits qui ciblent également les partitions avec un micrologiciel persistant, nous ne savons donc pas pourquoi Google n'impose pas de protection contre la restauration.
Membre senior XDA npjohnson, membre de l'équipe LineageOS, suppose qu'exiger une protection contre la restauration sur les partitions avec un micrologiciel persistant serait nécessitent des liens avec le chargeur de démarrage secondaire (SBL) et le chargeur de démarrage extensible (XBL), car ces partitions sont montées plus tôt dans le démarrage processus. Il serait coûteux pour les petits constructeurs OEM d'implémenter des XBL personnalisés pour correspondre aux modems personnalisés et autres partitions persistantes. alors peut-être que Google n'en fait pas une exigence pour permettre aux fabricants d'appareils de répondre plus facilement aux dernières exigences du CDD.
Comment vérifier si votre téléphone prend en charge AVB 2.0
Il existe deux commandes shell ADB que vous pouvez utiliser pour vérifier si votre téléphone prend en charge AVB 2.0.
adb shell
dumpsys package | grep "verified_boot"OU
adb shell
getprop | grep "avb"Si le résultat de la première commande est "android.software.verified_boot", alors AVB 2.0 est pris en charge. Si le résultat de la deuxième commande affiche « [ro.boot.avb_version] » et « [ro.boot.vbmeta.avb_version] » et répertorie un numéro de version pour chacun, alors elle est prise en charge.
Démarrage vérifié et développement personnalisé
Android Verified Boot n'affecte pas vraiment la plupart des utilisateurs de ROM personnalisées, bien qu'il ajoute une couche de sécurité supplémentaire que vous devez contourner dans certains cas. Par exemple, flasher une image système générique nécessite la désactivation d'AVB. La modification de certaines partitions comme le fournisseur sur le OnePlus 6 nécessite également de désactiver AVB, comme je l'ai appris récemment. Selon npjohnson, AVB 2.0 correctement implémenté permet aux images de démarrage personnalisées de fonctionner avec un chargeur de démarrage verrouillé. Nous verrons comment l'inclusion d'AVB 2.0 sur les appareils livrés avec Android Pie affecte le paysage, mais nous espérons que cela n'entraînera pas de situations comme celle-ci. récente alerte aux briques dans la communauté Xiaomi Redmi Note 5 Pro. L'AVB 2.0 obligatoire n'est qu'un autre moyen pour Google de améliorer la sécurité de la plateforme Android, mais le plus grand changement, à notre avis, est le refonte des accords OEM pour imposer des correctifs de sécurité réguliers.