Masquer l'accès root dans Magisk est sur le point de devenir beaucoup plus difficile à réaliser grâce à un récent changement dans SafetyNet apportant une attestation matérielle.
En mars, quelques utilisateurs avec Magisk installé remarqué que leurs appareils échouaient à l’attestation SafetyNet. Cette nouvelle a troublé la communauté de XDA car elle signifie que de nombreuses applications bancaires/financières cruciales et des jeux populaires comme Pokémon Go et Fate/Grand Order refusaient de fonctionner sur des appareils rootés. Pendant un certain temps, il a semblé que les restrictions renforcées de SafetyNet avaient été levées, pour ensuite être à nouveau déployées pour une poignée d'utilisateurs au cours des dernières semaines. Cependant, Google a discrètement confirmé début mai qu'il testait l'attestation matérielle pour Réponses SafetyNet, ce qui a empêché Magisk de masquer l'état de déverrouillage du chargeur de démarrage dans Mars. Si ce changement est largement déployé, cela signifie que les utilisateurs devront choisir entre avoir accès aux ROM/noyaux/etc root/personnalisés. ou leurs applications et jeux bancaires préférés. L’un des plus grands attraits d’Android pour les utilisateurs expérimentés pourrait bientôt disparaître.
Pour récapituler cette série d’événements, il faut d’abord parler de SafetyNet lui-même. SafetyNet est un ensemble d'API dans les services Google Play. L'API d'attestation SafetyNet est l'une de ces API et elle peut être appelée par des applications tierces pour vérifier si l'environnement logiciel de l'appareil a été falsifié de quelque manière que ce soit. L'API vérifie diverses choses telles que les signes des binaires du superutilisateur, l'état de déverrouillage du chargeur de démarrage, etc. Lorsque vous rootez un appareil avec Magisk, il « [crée] un « environnement sûr » isolé pour le processus de détection [SafetyNet], 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 », selon XDA Senior Recognized Developer topjohnwu. Cela permet à l'utilisateur de rooter son téléphone tout en garantissant que l'API renvoie toujours "false" pour toute vérification de déverrouillage du chargeur de démarrage. Cette méthode permettant de contourner la détection de déverrouillage du chargeur de démarrage de SafetyNet a fonctionné pour Magisk ces derniers temps. années, mais c'est uniquement parce que Google a hésité à vérifier l'intégrité de l'image de démarrage à l'aide du matériel. attestation. En mars, il semblait que Google commençait enfin à utiliser l'attestation matérielle dans SafetyNet pour vérifier le image de démarrage, mais nous n'avons jamais reçu de déclaration officielle de Google confirmant le changement et seuls quelques utilisateurs l'ont été. affecté. Comme repéré par un membre senior de XDA DéplacementCependant, Google a confirmé le 5 mai 2020 que les réponses de l'API d'attestation SafetyNet de certains appareils incluent désormais des vérifications matérielles.
Sur le groupe Google pour les « clients de l'API SafetyNet », Google a détaillé une nouvelle fonctionnalité pour l'API d'attestation: évaluationType. La réponse JSON Web Signature (JWS) de certains appareils aura un champ nommé «evaluationType» qui «fournira aux développeurs un aperçu dans les types de signaux/mesures qui ont contribué à chaque réponse individuelle de l'API d'attestation SafetyNet." L'un des jetons pris en charge dans ce champ se trouve "HARDWARE_BACKED" qui indique que l'API "[a utilisé] les fonctionnalités de sécurité matérielles disponibles du périphérique distant (par exemple. attestation de clé matérielle) pour influencer [son] évaluation." Google affirme qu'ils "évaluent et ajustent actuellement les critères d'éligibilité pour les appareils sur lesquels nous nous appuierons sur du matériel fonctionnalités de sécurité." Cela signifie que, sur certains appareils, les services Google Play utilisent désormais une attestation matérielle pour détecter que le logiciel de l'appareil n'a pas été altéré. Google n'a pas officiellement documenté ce changement en dehors de l'annonce du groupe Google, donc certains développeurs qui utilisent SafetyNet peuvent Je ne suis pas au courant de ce changement (et je ne vérifie donc pas encore le champ "HARDWARE_BACKED" dans les réponses JWS.) Cependant, pour les applications qui recherchent ce champ, il n'y a désormais aucun moyen de leur masquer l'accès root, à condition que votre appareil fasse partie du test effectué par Google. en cours d'exécution.
Selon topjohnwu, l'attestation matérielle signifie que les services Google Play « [envoient] désormais un certificat de magasin de clés non modifié aux serveurs SafetyNet, [vérifient] sa légitimité et [vérifie] les données d'extension de certificat pour savoir si votre appareil [a] vérifié le démarrage activé (état du chargeur de démarrage). Étant donné que les clés privées à partir desquelles les certificats du magasin de clés sont dérivés sont soutenus par l'environnement sécurisé isolé du téléphone, les récupérer impliquerait de mettre en échec la sécurité de l'environnement d'exécution de confiance (TEE) du téléphone ou de la sécurité matérielle dédiée (HSM). Si l'on parvenait d'une manière ou d'une autre à divulguer une clé privée, le les clés seraient rapidement révoquées une fois que Google l'a découvert. Google offre des centaines de milliers de dollars de récompenses pour toute faille de sécurité critique affectant le TEE des téléphones Pixel, ce qui montre simplement qu'il est incroyablement improbable que ce soit un moyen potentiel de contourner la détection du déverrouillage du chargeur de démarrage de toute façon.
Une autre façon potentielle pour Magisk de continuer à usurper l'état de déverrouillage du chargeur de démarrage consiste à modifier le code côté client de SafetyNet pour toujours utiliser l'évaluation BASIC. Comme notes de topjohnwu, cependant, cela nécessiterait l'injection de code personnalisé dans les services Google Play via un framework de hooking tel que Xposed Framework. Ceci est non seulement difficile à faire car les services Google Play sont très obscurcis, mais il est également impossible de le cacher car « certaines analyses de l'espace mémoire révéleront une manipulation du code très complexe ». facilement." De plus, cela ne fonctionnerait que si les serveurs de Google continuent d'accepter les évaluations BASIC et si les évaluations HARDWARE_BACKED ne sont pas appliquées sur les appareils prenant en charge eux. (Les réponses SafetyNet « [proviennent] des serveurs de Google et sont signées avec la clé privée de Google », selon topjohnwu, de sorte que les réponses réelles ne peuvent pas être usurpées.)
Depuis Android 7 Nougat, Google exige que tous les appareils disposent d'un environnement sécurisé isolé, ce qui signifie que ce changement dans la façon dont SafetyNet vérifie le déverrouillage du chargeur de démarrage affectera la plupart des appareils hors service là. Étant donné que les appareils plus anciens sans environnement sécurisé isolé ne peuvent évidemment pas effectuer d'attestation matérielle, Magisk pourra toujours masquer l'accès root sur ces appareils. Mais si ce changement se généralise, tout le monde devra faire un choix difficile entre l’accès root et les applications bancaires.
Malheureusement, il existe probablement de nombreuses applications qui utilisent les contrôles SafetyNet alors qu'elles n'en ont pas réellement besoin. Un exemple cité par topjohnwu est l'application officielle McDonald's, qui refuse apparemment de s'exécuter sur un appareil déverrouillé par le chargeur de démarrage. Sur Twitter, topjohnwu dénonce les applications qui abusent de l'API comme créant un environnement hostile pour les utilisateurs expérimentés. Développeur reconnu XDA Quinny899 se joint à une anecdote sur la façon dont son équipe a envisagé d'utiliser SafetyNet pour vérifier l'état de sécurité des appareils. Ils ont finalement décidé de ne pas aller jusqu'au bout puisque l'application de son équipe crypte toutes les données sensibles avec lesquelles elle travaille. SafetyNet, affirme-t-il, ne devrait pas être utilisé à la place de pratiques appropriées de sécurité et de traitement des données, en particulier si l'on considère la possibilité d'exploits de superutilisateur.
Pour plus d'informations sur la manière dont le nouveau changement SafetyNet affecte Magisk, consultez le site de topjohnwu. excellente FAQ sur Twitter. Si vous souhaitez simplement vérifier si votre appareil fait partie du nouveau test SafetyNet de Google, vous pouvez suivre ce guide par XDA Senior Member Displax ou téléchargez la dernière version de Magisk Manager.
Cet article a été mis à jour à 10 h 46 HNE le 30 juin 2020 pour corriger le fait que Google ne verse des récompenses que pour les vulnérabilités TEE trouvées dans les téléphones Pixel. De plus, des détails ont été ajoutés concernant la dernière version de Magisk Manager qui affiche désormais le champ évaluationType dans le vérificateur SafetyNet intégré.