Flaz's Hotline

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== SafetyNet et CTS ======
===== De quoi s'agit-il =====
Google propose aux développeuses un service de contrôle d'intégrité((Les critères sont définis par Google.)) 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((En juillet 2023.)) par des applications bancaires et des jeux en ligne((Cela peut également être le cas de mods installés par les fabricants d'androphones ou des opérateurs de téléphonie.)).
===== Plus précisément =====
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 dans tout ça ? ===
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.

===== Conséquences =====
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((Il peut également être beaucoup moins sûr. Tout dépend des précautions que l'on prend sort des chemins balisées par les fabricants et opérateurs.)) 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é"((Pour autant que ce qualificatif ait un sens, parlant des ces services.)) 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. 

===== Contre-mesures =====
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((Google Play Services, les services le backend de l'appli, les normes de développement…)) 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((D'autres stratégies de coexistence ont également été mise en œuvre, comme le multiboot.)). 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((Juillet 2023.)) avec l'arrêt programmé de la //SafetyNet Attestation API// et son remplacement par la //Play Integrity API//.

==== Solutions ====
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.


===== En savoir plus =====
  * [[https://www.xda-developers.com/how-to-pass-safetynet-android/|How to pass SafetyNet on Android after rooting or installing a custom ROM]] (xda-developers.com) (en) (mars 2023)
  * [[https://developer.android.com/training/safetynet/attestation|SafetyNet Attestation API]] (android.com) (en)
  * [[https://developer.android.com/training/safetynet/deprecation-timeline|Discontinuing the SafetyNet Attestation API]] (android.com) (en)
  * [[https://www.xda-developers.com/safetynet-hardware-attestation-hide-root-magisk/|SafetyNet's dreaded hardware attestation is rolling out, making it much harder for Magisk to hide root]] (xda-developers.com) (en) (juin 2020)
  * [[https://developer.android.com/google/play/integrity/overview|Overview of the Play Integrity API]] (android.com) (en)
  * [[https://www.xda-developers.com/play-integrity-api-checker-android-app/|This app lets you check the unmodified status of your Android device using the Play Integrity API]] (xda-developers.com) (en) (sept 2022)
  * [[https://source.android.com/docs/compatibility/cts?hl=en|Compatibility Test Suite]] (android.com) (en)
  * [[https://source.android.com/docs/security/features/verifiedboot/avb?hl=en|Android Verified Boot]] (android.com) (en)