SafetyNet et CTS

Google propose aux développeuses un service de contrôle d'intégrité¹⁾ de l'environnement d'exécution de leur applications. Concrètement, un app installée sur un androphone peut s'assurer que cet appareil est conforme aux critères d'intégrité définis par Google. Si l'androphone n'est pas conforme, l'app pourra refuser de fonctionner ou ne donner accès qu'à certaines fonctionnalités. En plus d'être utilisée par Google Play Store, cette possibilité l'est principalement²⁾ par des applications bancaires et des jeux en ligne³⁾.

SafetyNet se présente comme un ensemble d'API mises à disposition à travers Google Play Services. L'une des API/service phare de SafetyNet n'est autre que “SafetyNet Attestation API”. Elle effectue une série de tests dont elle expose les résultats à travers des services tels que ctsProfileMatch, basicIntegrity, evalutationType.

Réussir le test signifie que le système, les applications et la configuration d'un androphone sont conformes aux attendus du code informatique implémentant les services de l'API. Cela signifie deux choses. D'une part, ces attendus peuvent évoluer au fil du temps. Ainsi, sans aucun changement de votre part, votre androphone peut subitement échouer au test qu'il réussissait jusqu'alors. D'autre part, les attendus fonctionnels du code reposent eux-mêmes sur une interprétation et l'exécution de fragments de code implantés dans l'androphone. Autrement dit, ils ne sont pas une preuve.

CTS, littéralement “Compatibility Test Suite” est un outil permettant aux développeuses d'une application de s'assurer que leur code passe un ensemble de tests unitaires et fonctionnels de compatibilité avec exigences de programmation fixées pour Android. Une application qui passe les tests dispose d'un profil de compatibilité.

Lorsque cette application est installée sur un androphone, il est possible de s'assurer que le code informatique présent est bien celui qui correspond au profil. Cela permet notamment de s'assurer que l'application n'a pas été altérée.

En pratique, on peut se retrouver dans l'impossibilité d'utiliser certaines applications. Cela peut arriver, même sur un androphone auquel on n'a apporté aucune modification.

Toutefois, le cas le plus courant de non réussite des tests nécessaires à obtention d'une attestation SafetyNet est celui où l'on apporte des modifications son androphone : installation d'un système modifié open source, installation d'un recovery open source, rootage, etc. Bref, tout ce qui permet de se soustraire à l'intrusion des constructeurs et des opérateurs téléphoniques dans nos activités Autrement dit, un androphone qui n'obtient pas l'attestation SafetyNet peut être plus sûr⁴⁾ qu'un autre qui l'obtient.

De nombreuses modifications ne peuvent être apportées avant d'avoir déverrouiller le bootloader de son appareil. Or, ce seul déverrouillage entraîne le refus de délivrance d'une attestation SafetyNet L'utilisatrice peut, plus ou moins (selon ses usages), être mise dans l'impossibilité d'utiliser certaines applications. Elles doit alors se détourner de ces applications ou mettre en place des contre-mesures.

Les conséquences de non-obtention comme les critères d'obtention ne sont pas immuables. La tendance étant à une restriction dans la liberté d'utilisation, une évolution probable est que la position médiane consistant à conserver un usage “modéré”⁵⁾ des Google Play Services deviendra intenable. Tant qu'AOSP existera, le clivage entre un usage inscrit dans la société de contrôle (GAFAM, opérateurs, banques, États…) et usage alternatif d'Android est probablement appelé à s'accentuer. D'un côté un packages de plus en plus obscur et difficile à démêler. De l'autre, un écosystème ouvert et indépendant.

La promesse de SafetyNet est de fournir à chaque application des informations sur son “environnement d'exécution”. En simplifiant, cela implique trois catégories d'acteurs : les développeuses d'applications, Google⁶⁾ et l'environnement. Ce dernier acteur intervient sous deux formes.

D'une part, il est ce sur quoi les applications demandeuses veulent avoir des informations. D'autre part, il est ce par quoi, les informations de bases sont collectées. Par exemple, l'état de déverrouillage du bootloader n'est pas un effectué par un contrôle direct mais à travers un test informatique. Le bootloader et SafetyNet était distincts, ce dernier n'a d'autre recours que de demander à l'“environnement” des informations lui permettant d'en déduire un état (celui du bootloader) qui fait précisément partie de cet environnement.

Cette dualité entre SafetyNet et l'environnement ouvre la possibilité de fournir à SafetyNet les informations qu'il attend pour accorder une attestation de conformité. Pour y parvenir, il faut identifier les informations demandées et les moyens utilisés pour obtenir ces informations⁷⁾. Si l'on parvient à intervenir sur les réponses faites aux demandes formulées par SafetyNet, sans qu'il détecte notre intervention, le but recherché sera atteint : Les mesures effectuées par SafetyNet sur l'environnement récupèrent une information produite par une contre-mesure.

Il s'en est suivi un cycle classique de course entre mesures et contre-mesures qui est en train de prendre fin⁸⁾ avec l'arrêt programmé de la SafetyNet Attestation API et son remplacement par la Play Integrity API.

Selon les versions d'Android et les appareils, les solutions sont plus ou moins simples à mettre en œuvre : patch statique ou dynamique, multi-boot, applications… Sans entrer dans les détails d'installation, de configuration ni de périmètres fonctionnel, voici une liste de solutions applicables : Magisk, Universal SafetyNet Fix, Shamiko, ih8sn.

• How to pass SafetyNet on Android after rooting or installing a custom ROM (xda-developers.com) (en) (mars 2023)
• SafetyNet Attestation API (android.com) (en)
• Discontinuing the SafetyNet Attestation API (android.com) (en)
• SafetyNet's dreaded hardware attestation is rolling out, making it much harder for Magisk to hide root (xda-developers.com) (en) (juin 2020)
• Overview of the Play Integrity API (android.com) (en)
• This app lets you check the unmodified status of your Android device using the Play Integrity API (xda-developers.com) (en) (sept 2022)
• Compatibility Test Suite (android.com) (en)
• Android Verified Boot (android.com) (en)