En mars, quelques utilisateurs avec Magisk installé ont remarqué que leurs appareils échouaient à l’attestation SafetyNet. Cette nouvelle a troublé la communauté de XDA car cela 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 enracinés. Pendant un certain temps, il semblait que les restrictions renforcées dans SafetyNet étaient retirées, pour ensuite être déployées à nouveau 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 les réponses SafetyNet, ce qui a empêché Magisk de masquer le statut de déverrouillage du chargeur de démarrage en mars. Si ce changement se déploie largement, cela signifiera que les utilisateurs devront choisir entre avoir accès à la racine / aux ROM personnalisées / aux noyaux / etc. ou leurs applications et jeux bancaires préférés. L’un des plus grands appels d’Android pour les utilisateurs expérimentés pourrait bientôt disparaître.
Pour résumer cette série d’événements, nous devrions d’abord parler de SafetyNet lui-même. SafetyNet est un ensemble d’API dans les services Google Play. L’API SafetyNet Attestation 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é altéré de quelque manière que ce soit. L’API vérifie diverses choses comme les signes de binaires de superutilisateur, le statut de déverrouillage du chargeur de démarrage, etc. Lorsque vous rootez un appareil avec Magisk, il s’agit d’un « environnement sûr » isolé pour le processus de détection, et il passe par l’API de Google pour créer un résultat SafetyNet légitime qui ne reflète pas l’état réel de l’appareil », selon topjohnwu, développeur reconnu par XDA. Cela permet à l’utilisateur de rooter son téléphone tout en s’assurant que l’API renvoie toujours « false » pour toutes les vérifications de déverrouillage du chargeur de démarrage. Cette méthode de contournement de la détection de déverrouillage du chargeur de démarrage de SafetyNet fonctionne pour Magisk depuis quelques années, mais c’est uniquement parce que Google a résisté à la vérification de l’intégrité de l’image de démarrage à l’aide d’une attestation matérielle. En mars, il semblait que Google commençait enfin à utiliser une attestation matérielle dans SafetyNet pour vérifier l’image de démarrage, mais nous n’avons jamais reçu de déclaration officielle de Google confirmant le changement et seuls quelques utilisateurs ont été affectés. Cependant, comme l’a repéré Displax, membre senior de XDA, 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 API SafetyNet « , Google a détaillé une nouvelle fonctionnalité pour l’API d’attestation : evaluationType. La réponse JSON Web Signature (JWS) de certains appareils aura un champ nommé « evaluationType » qui « fournira aux développeurs un aperçu des types de signaux / mesures qui ont contribué à chaque réponse de l’API d’attestation SafetyNet individuelle. »L’un des jetons pris en charge dans ce champ est « HARDWARE_BACKED » qui indique que l’API « les fonctionnalités de sécurité matérielles disponibles du périphérique distant (par exemple, l’attestation de clé matérielle) pour influencer l’évaluation. »Google dit qu’ils « évaluent et ajustent actuellement les critères d’éligibilité pour les appareils sur lesquels nous compterons sur des fonctionnalités de sécurité soutenues par du matériel. »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é falsifié. Google n’a pas officiellement documenté ce changement en dehors de l’annonce dans le groupe Google, de sorte que certains développeurs qui utilisent SafetyNet peuvent ne pas être au courant de ce changement (et ne recherchent donc pas encore le champ « HARDWARE_BACKED » dans les réponses JWS.) Cependant, pour les applications qui vérifient ce champ, il n’y a désormais aucun moyen de leur cacher l’accès root, à condition que votre appareil fasse partie du test que Google exécute.
Selon topjohnwu, l’attestation matérielle signifie que Google Play Services fournit désormais un certificat de magasin de clés non modifié aux serveurs SafetyNet, sa légitimité et les données d’extension de certificat pour savoir si le démarrage vérifié de votre appareil est activé (état du chargeur de démarrage). »Étant donné que les clés privées à partir desquelles les certificats de magasin de clés sont dérivés sont sauvegardées par l’environnement sécurisé isolé du téléphone, leur récupération impliquerait de compromettre la sécurité de l’environnement d’exécution de confiance (TEE) ou du module de sécurité matérielle dédié (HSM) du téléphone. Si l’on était en mesure de divulguer une clé privée, les clés seraient rapidement révoquées une fois que Google l’aurait découverte. Google offre des centaines de milliers de dollars de récompenses pour toutes les vulnérabilités de sécurité critiques affectant le TEE dans les téléphones Pixel, ce qui montre qu’il est incroyablement peu probable que ce soit une avenue potentielle pour contourner la détection de 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 DE BASE. Comme le note topjohnwu, cependant, cela nécessiterait d’injecter du code personnalisé dans les services Google Play via un framework d’accrochage comme le framework Xposed. Ce n’est pas seulement difficile à faire car les services Google Play sont très obscurcis, mais il est également impossible de le cacher car « une analyse de l’espace mémoire révélera très facilement la manipulation du code. »En outre, cela ne fonctionnerait également que si les serveurs de Google continuent d’accepter les évaluations DE BASE et si les évaluations HARDWARE_BACKED ne sont pas appliquées sur les appareils qui les prennent en charge. (Les réponses SafetyNet « des serveurs 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 a exigé que tous les appareils disposent d’un environnement sécurisé isolé, ce qui signifie que cette modification de la façon dont SafetyNet vérifie le déverrouillage du chargeur de démarrage affectera la plupart des appareils disponibles. É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 déroule largement, 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 vérifications SafetyNet lorsqu’elles n’en ont pas réellement besoin. Un exemple cité par topjohnwu est l’application officielle de McDonald’s, qui refuse apparemment de fonctionner 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. Le 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é de l’appareil. Ils ont finalement décidé de ne pas aller au bout puisque l’application de son équipe crypte toutes les données sensibles avec lesquelles elle fonctionne. SafetyNet, soutient-il, ne devrait pas être utilisé au lieu de pratiques de sécurité et de traitement des données appropriées, en particulier lorsque l’on considère la possibilité d’exploits de superutilisateur.
Je préconise @AndroidDev de restreindre l’évaluation de SafetyNet soutenue par le matériel aux « vraies » applications sensibles à la sécurité. Les développeurs doivent passer par un processus d’application pour qualifier ce niveau d’accès à l’API. Il est ridicule pour McDonalds de refuser de fonctionner sur un périphérique déverrouillé par le chargeur de démarrage.
– John Wu (@topjohnwu) Juin 29, 2020
Pour plus d’informations sur la façon dont le nouveau changement de SafetyNet affecte Magisk, consultez l’excellente FAQ de topjohnwu sur Twitter. Si vous souhaitez simplement vérifier si votre appareil fait partie du nouveau test SafetyNet de Google, vous pouvez suivre ce guide de Displax, membre senior de XDA, ou télécharger la dernière version de Magisk Manager.
Mise à jour de Magisk Manager pour refléter le champ evaluationType dans les contrôles SafetyNet afin que les gens puissent commencer à compter les derniers jours de gloire
pic.twitter.com/x61tGjM7IK
– John Wu (@topjohnwu) Juin 30, 2020
Cet article a été mis à jour à 10h46 HNE le 30 juin 2020 pour corriger le fait que Google ne paie que les récompenses 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 evaluationType dans le vérificateur SafetyNet intégré.
- À propos de l’auteur
- Lire La Suite
- Google forme une alliance Android Ready SE pour favoriser l’adoption de clés de voiture numériques et de permis de conduire
- Fairphone 2 de 2015 reçoit désormais la mise à jour officielle d’Android 9 Pie
- Le Moto G50 de Motorola arbore une puce 5G économique et un prix bas
- ASUS publie de nouvelles mises à jour pour le ROG Phone 5, le ROG Phone 3 et le ROG Phone II avec des correctifs de sécurité et des corrections de bugs
À propos de l’auteur
Mishaal Rahman
Je suis le rédacteur en chef de XDA. En plus des dernières nouvelles sur le système d’exploitation Android et les appareils mobiles, je gère tous les contenus éditoriaux et critiques sur le Portail. Conseils / demandes des médias: [email protected] .
Lire La Suite
-
Google forme une alliance Android Ready SE pour favoriser l’adoption de clés de voiture numériques et de permis de conduire
-
Fairphone 2 de 2015 reçoit désormais la mise à jour officielle d’Android 9 Pie
-
Le Moto G50 de Motorola arbore une puce 5G économique et un prix bas
-
ASUS publie de nouvelles mises à jour pour le ROG Phone 5, le ROG Phone 3 et le ROG Phone II avec des correctifs de sécurité et des corrections de bugs
