Le développeur de Magisk a découvert que Google a peut-être commencé à utiliser des vérifications matérielles pour déterminer si un périphérique a été déverrouillé par le chargeur de démarrage.
Développeur reconnu XDA topjohnwuLe projet "Magisk" de est essentiellement devenu synonyme de "root" dans la communauté Android. L'une des principales raisons pour lesquelles il est si populaire est qu'il peut masquer le fait que l'utilisateur a modifié son appareil. Cependant, Google pourrait sévir contre la capacité de Magisk à masquer l'état de déverrouillage du chargeur de démarrage des applications.
Pour rooter votre téléphone, vous devez généralement déverrouiller le chargeur de démarrage, qui vous permet de flasher des images de démarrage modifiées. Cela est nécessaire car Magisk modifie l'image de démarrage pour usurper l'état du chargeur de démarrage et/ou les vérifications de l'état de démarrage vérifié. L'API d'attestation SafetyNet de Google, qui fait partie des services Google Play, est utilisée pour indiquer à une application si elle s'exécute sur un appareil falsifié; si l'API SafetyNet détecte que le chargeur de démarrage a été déverrouillé, elle renverra un état d'échec pour la vérification « Intégrité de base ». Les appareils qui échouent à cette vérification peuvent ensuite être exclus des applications qui utilisent l'API SafetyNet pour déterminer l'intégrité de l'appareil; ces applications incluent généralement des applications bancaires, des applications de paiement (comme Google Pay) et de nombreux jeux en ligne (comme Pokémon Go). Cependant, comme l'API SafetyNet n'a jusqu'à présent utilisé que des vérifications logicielles pour déterminer si l'appareil a été falsifié, Magisk peut simplement usurper l'identité de l'utilisateur. chargeur de démarrage et/ou statut de démarrage vérifié car il est installé à un niveau inférieur et avec des privilèges plus élevés que les services Google Play et autres espaces utilisateur applications. Comme l'explique topjohnwu, MagiskHide « [crée] un « environnement sûr » isolé pour le processus de détection, et il passe par l'API de Google pour créer un
légitime Résultat SafetyNet qui ne reflète pas l'état réel de l'appareil.Récemment, cependant, les utilisateurs ont remarqué que leurs appareils déverrouillés par le chargeur de démarrage échouaient au contrôle d'intégrité de base de SafetyNet, même s'ils utilisaient Magisk pour corriger l'image de démarrage. Selon topjohnwu, cela est dû au fait que Google a peut-être implémenté une attestation de clé au niveau matériel pour vérifier que l'image de démarrage n'a pas été falsifiée. Plus précisément, cela signifie que les services Google Play « [envoient] un certificat de magasin de clés non modifié aux serveurs SafetyNet, vérifient sa légitimité et vérifient données d'extension de certificat pour savoir si votre appareil [a] vérifié le démarrage activé (état du chargeur de démarrage). " Cela signifie qu'il peut ne plus être possible de masquer le fait que le chargeur de démarrage a été déverrouillé, ce qui entraînera le dysfonctionnement d'applications comme Google Pay et Pokémon Go normalement.
Comme l'a noté topjohnwu, ce changement dans la façon dont SafetyNet vérifie l'état de déverrouillage du chargeur de démarrage passe par une mise à jour côté serveur de l'API SafetyNet contenue dans les services Google Play. Cependant, tous les utilisateurs n'échouent pas à ces contrôles SafetyNet mis à jour, de sorte que la nouvelle attestation de clé au niveau matériel n'est peut-être pas encore largement appliquée.
Nous avons vu topjohnwu surmonter à maintes reprises des obstacles techniques. Google déploie fréquemment de nouveaux contrôles dans SafetyNet que topjohnwu découvre et contourne ensuite dans Magisk. Chaque nouvelle version d'Android apporte des modifications à la structure des partitions ou à l'image de démarrage, obligeant topjohnwu à étudier les modifications, puis à implémenter une nouvelle méthode de correction. Cependant, même topjohnwu pourrait avoir du mal à trouver un contournement cette fois-ci.
En effet, cette fois-ci, la solution de contournement impliquerait de pirater le micrologiciel TEE (Trusted Execution Environment) des appareils afin de récupérer la clé privée. Cependant, cela est incroyablement difficile à réaliser car cela nécessite de trouver une vulnérabilité dans le micrologiciel conçu pour être incroyablement sécurisé. En fait, de nombreuses entreprises proposent des paiements de plusieurs centaines de milliers de dollars si une telle vulnérabilité était découverte. Google, par exemple, paie 250 000 $ pour les vulnérabilités d'exécution de code à distance dans l'environnement d'exécution de confiance de Pixel, et jusqu'à 1 000 000 $ pour les vulnérabilités dans le Titan M puce de sécurité. Même si une clé privée devait être divulguée, il est peu probable qu'elle soit d'une grande utilité puisque Google peut révoquer la clé à distance il ne peut donc pas être utilisé pour vérifier l’intégrité des appareils.
Une fois que l'attestation de clé au niveau matériel sera largement appliquée pour SafetyNet, la plupart des appareils dotés de chargeurs de démarrage déverrouillés exécutant Android 8.0 Oreo ou version ultérieure ne réussiront pas le contrôle d'intégrité de base de SafetyNet. En effet, tous les appareils lancés avec Android 8.0 Oreo ou version ultérieure doivent disposer d'un magasin de clés matérielles implémenté dans un TEE. Certains appareils disposent même aujourd'hui de modules matériels de sécurité (HSM) dédiés qui rendent l'exploitation encore plus difficile en éloignant le TEE du processeur principal; le Titan M dans le Pixel 4 et La nouvelle puce de sécurité de Samsung dans le Galaxy S20 en sont des exemples.
Topjohnwu explique également que d'autres solutions de contournement potentielles sont soit impossibles, soit très difficiles. L'utilisation de Xposed Framework pour modifier l'API d'attestation SafetyNet dans les services Google Play ne fonctionnera probablement pas puisque « des contrôles SafetyNet appropriés vérifieront les résultats sur un serveur distant, et non sur [le] périphérique qui peut être manipulé par des frameworks d'injection de code. » De plus, les services Google Play sont très obscurcis, ce qui rend la création d'un tel module Xposed incroyablement difficile au premier abord. lieu. L'usurpation d'un résultat de test SafetyNet ne sera pas non plus réalisable puisque les réponses SafetyNet "proviennent des serveurs de Google et sont signées avec la clé privée de Google".
Google a la possibilité de renforcer les contrôles SafetyNet à l'aide d'une attestation de clé matérielle depuis plusieurs années maintenant. Le fait qu'ils se soient abstenus de le faire pendant 3 ans a permis aux utilisateurs de profiter des modules root et Magisk sans sacrifier la possibilité d'utiliser les applications bancaires. Cependant, il semble que la capacité de Magisk à masquer efficacement l'état de déverrouillage du chargeur de démarrage touche bientôt à sa fin. C'est un changement que nous attendions depuis des années, mais nous sommes tristes de le voir enfin entrer en vigueur. Nous espérons que Google mettra à jour l'API d'attestation SafetyNet pour indiquer si la vérification de l'état a utilisé des informations matérielles. attestation, car cela permettrait aux développeurs d'applications de décider s'ils souhaitent bloquer tous les utilisateurs ayant déverrouillé l'application. chargeur de démarrage.
Merci à Daniel Micay (@DanielMicay) pour sa contribution à ce sujet !