SafetyNet vs MagiskHide : où en est-on à la mi-2020 ?

(29 juin 2020) Il semble que Google soit prudent et prépare un nouveau champ dans le cadre de la réponse SafetyNet.

Selon le l'équipe des clients de l'API SafetyNet

Nous avons commencé à déployer une nouvelle fonctionnalité qui donnera aux développeurs un aperçu des types de signaux/mesures qui ont contribué à chaque réponse individuelle de l'API d'attestation SafetyNet.

Nos réponses JWS disposent désormais d'un nouveau champ facultatif appelé evaluationType. La valeur de ce champ sera une liste de chaînes de caractères séparées par des virgules, chaque chaîne représentant une valeur de type énumération.

Actuellement, les chaînes de caractères suivantes peuvent être indiquées: :

• BASIQUE - Lorsque nous utilisons des signaux et des mesures typiques ainsi que des données de référence au cours de notre évaluation.
• HARDWARE_BACKED - Lorsque nous utilisons les fonctions de sécurité matérielles disponibles de l'appareil distant (par exemple, l'attestation de clé matérielle) pour influencer notre évaluation.

Exemples de valeurs de champ auxquelles vous pouvez vous attendre :

• {"evaluationType" : "BASIC"}
• {"evaluationType" : "BASIC,HARDWARE_BACKED"}

Nous sommes en train d'évaluer et d'ajuster les critères d'éligibilité pour les appareils pour lesquels nous nous appuierons sur des fonctions de sécurité matérielles. Veuillez donc ne pas utiliser la présence ou la valeur de ce champ comme un signal en soi (pour l'instant).

Notez que cette fonctionnalité n'a pas encore été officiellement documentée. Pour l'instant, nous la communiquons uniquement à cette liste d'annonces afin de recueillir des commentaires.

Nous vous encourageons à utiliser notre formulaire de retour d'information pour nous faire part de votre expérience de cette nouvelle fonctionnalité et de l'ensemble du service.

Merci et salutations, L'équipe des clients API de SafetyNet

Une fois les tests de cette nouvelle fonctionnalité terminés, il semble donc que l'attestation de clé adossée au matériel sera mise en place. Cela signifie qu'à partir de ce moment-là, SafetyNet sera en mesure de détecter l'état du bootloader/vérifié même si MagiskHide est activé.

John Wu continue de se battre

(mise à jour le 29 juin 2020)

John Wu tente de persuader Google de ne pas appliquer aveuglément l'attestation SafetyNet soutenue par le matériel. Il a tweeté :

Je préconise @AndroidDev de restreindre l'évaluation SafetyNet soutenue par le matériel aux "vraies" applications sensibles à la sécurité. Les développeurs devraient passer par un processus d'application pour obtenir ce niveau d'accès à l'API. Il est ridicule que McDonalds refuse de fonctionner sur un appareil dont le bootloader est déverrouillé.

Entre-temps, il semble que les contrôles SafetyNet échouent toujours même si le chargeur de démarrage est reverrouillé, comme nous le voyons ici, tweeté le 3 juillet 2020

Mauvaise nouvelle : il est confirmé que pour ceux qui veulent reverrouiller leur bootloader avec des images auto-signées (possible sur les appareils Pixel), SafetyNet avec l'évaluation HARDWARE-BACKED sera toujours PAS réussir le contrôle CTS.

(Mise à jour le 13 décembre 2020) John Wu tweets actuels

Permettez-moi de mettre les choses au clair : comme j'ai un emploi à temps plein, je n'ai pas beaucoup de temps à consacrer à Magisk ; j'ai besoin d'établir des priorités. L'évaluation basée sur le HW n'est pas pratique à "hacker" (à part des astuces pour le faire revenir à basic), et j'ai perdu tout intérêt à améliorer la façon actuelle de cacher.