API SafetyNet Attestation

L'API SafetyNet Attestation est une API de protection contre les utilisations abusives qui permet aux développeurs d'applications d'évaluer l'appareil Android sur lequel leur application s'exécute. L'API doit être utilisée dans le cadre de votre système de détection des abus afin de déterminer si vos serveurs interagissent avec votre application authentique s'exécutant sur un appareil Android authentique.

L'API SafetyNet Attestation fournit une attestation avec signature cryptographique qui évalue l'intégrité de l'appareil. Pour créer l'attestation, l'API examine l'environnement logiciel et matériel de l'appareil, recherche d'éventuels problèmes d'intégrité et compare les résultats aux données de référence des appareils Android approuvés. L'attestation générée est liée au nonce fourni par l'application appelante. L'attestation contient également un code temporel de génération et des métadonnées concernant l'application à l'origine de la demande.

L'API n'est pas conçue pour répondre aux cas d'utilisation suivants :

Agir en tant que mécanisme autonome de lutte contre les utilisations abusives ou de sécurité des applications. Veuillez l'utiliser conjointement avec les bonnes pratiques concernant la sécurité des applications publiées et votre suite de signaux de lutte contre les utilisations abusives spécifiques au produit.
Fonctionner lorsque l'appareil n'est pas connecté à Internet. Dans ce cas, l'API renvoie une erreur.
Avoir sa réponse interprétée directement dans l'application appelante. Transférez toute la logique de décision en matière de lutte contre les utilisations abusives vers un serveur sous votre contrôle.
Fournir des signaux précis sur les modifications du système. L'API propose des valeurs booléennes qui expriment différents niveaux d'intégrité du système.
Contenir des signaux pour des cas d'utilisation spécifiques à l'application, tels que les identifiants d'appareil, l'état de l'émulation GPS et l'état du verrouillage de l'écran.
Remplacer ou mettre en œuvre des contrôles DRM stricts.
Vérifier uniquement si l'appareil est en mode root, car l'API est conçue pour vérifier son intégrité globale.

Présentation

L'API SafetyNet Attestation utilise le workflow suivant :

L'API SafetyNet Attestation reçoit un appel de votre application. Cet appel inclut un nonce.
Le service SafetyNet Attestation évalue l'environnement d'exécution et demande aux serveurs de Google une attestation signée des résultats de l'évaluation.
Les serveurs de Google envoient l'attestation signée au service SafetyNet Attestation sur l'appareil.
Le service SafetyNet Attestation renvoie cette attestation signée à votre application.
Votre application transfère l'attestation signée à votre serveur.
Ce serveur valide la réponse et l'utilise pour prendre des décisions en matière de lutte contre les utilisations abusives. Votre serveur communique ses résultats à votre application.

La figure 1 est une représentation graphique de ce processus :

**Figure 1**. Protocole de l'API SafetyNet Attestation

Remarque : Documentation supplémentaire et checklist

Tout au long de l'initialisation, de la configuration et de l'activation de l'API SafetyNet Attestation, et en plus de cette documentation principale, tenez compte des conseils suivants :

Obtenir une clé API

Pour appeler les méthodes de l'API SafetyNet Attestation, vous devez utiliser une clé API. L'API SafetyNet Attestation est obsolète. Vous ne pouvez donc plus demander de nouvelle clé API.

Quotas d'API et surveillance

Les quotas d'attribution par défaut par projet pour l'appel de l'API SafetyNet Attestation sont de 10 000 requêtes par jour pour votre base d'utilisateurs. Pour effectuer un volume plus important de requêtes d'intégrité, migrez vers l'API Play Integrity et demandez une augmentation des quotas en suivant les instructions de la documentation de l'API Play Integrity. Notez que le traitement des demandes de quotas prend quelques jours ouvrés. Il est donc recommandé de configurer la surveillance des quotas et les alertes associées pour éviter les situations d'urgence.

Remarque : Quels que soient les quotas provisionnés pour votre projet, les instances d'application individuelles sont limitées à un maximum de 5 requêtes par minute. Si cette limite est dépassée, toutes les requêtes restantes pendant cette minute renvoient une erreur.

Gardez ce comportement à l'esprit lorsque vous implémentez le mécanisme de nouvelle tentative de votre application.

Vérifier la version des services Google Play

Avant d'utiliser l'API SafetyNet Attestation, vous devez vous assurer que la bonne version des services Google Play est installée sur l'appareil de l'utilisateur. Si une version incorrecte est installée, votre application peut cesser de répondre après avoir appelé l'API. Si votre application détecte qu'une version incorrecte est installée, vous devez demander à l'utilisateur de mettre à jour l'application des services Google Play sur son appareil.

Pour vérifier si la version installée des services Google Play est compatible avec la version du SDK Android que vous utilisez, appelez la méthode isGooglePlayServicesAvailable(), comme indiqué dans l'extrait de code suivant :

if (GoogleApiAvailability.getInstance().isGooglePlayServicesAvailable(context)
        == ConnectionResult.SUCCESS) {
  // The SafetyNet Attestation API is available.
} else {
  // Prompt user to update Google Play services.
}

Sur les appareils exécutant la version 13.0 ou ultérieure des services Google Play, l'API SafetyNet Attestation est également compatible avec les clés API limitées à une application. Cette fonctionnalité réduit le risque d'utilisation accidentelle ou non autorisée de clés API soumises à des quotas. Pour utiliser cette fonctionnalité facultative, vérifiez que l'appareil dispose de la version 13.0 ou ultérieure des services Google Play, comme indiqué dans l'extrait de code suivant :

if (GoogleApiAvailability.getInstance()
    .isGooglePlayServicesAvailable(context, 13000000) ==
    ConnectionResult.SUCCESS) {
  // The SafetyNet Attestation API is available.
} else {
  // Prompt user to update Google Play Services.
}

Demander une attestation SafetyNet

Une fois que vous avez obtenu une clé API valide pour l'API Android Device Verification dans la console Google APIs, votre application peut utiliser le service SafetyNet Attestation. Pour ce faire, procédez comme suit :

Obtenez un nonce.
Demandez une attestation SafetyNet.
Transférez la réponse à votre serveur.
Utilisez la réponse sur votre serveur, ainsi que vos autres signaux de lutte contre les utilisations abusives, pour contrôler le comportement de votre application.

Pour que votre application reste réactive, exécutez ces étapes en dehors du thread d'exécution principal de votre application. Pour en savoir plus sur la création de threads d'exécution distincts, consultez la section Envoyer des opérations à plusieurs threads.

Vous devez effectuer cette vérification pour protéger toutes les actions critiques dans votre application, y compris les connexions, les événements d'achat et l'acquisition de nouveaux produits intégrés. Toutefois, les appels à l'API SafetyNet Attestation entraînent une latence, une consommation de données mobiles et une utilisation de la batterie accrues. Il est donc logique de trouver un équilibre entre sécurité et facilité d'utilisation. Par exemple, vous pouvez choisir de demander une attestation SafetyNet à la connexion et d'effectuer des revérifications au maximum toutes les 30 minutes. Vous pouvez également laisser votre serveur décider du moment où votre application demande une attestation, afin que les pirates informatiques aient plus de mal à prédire la date et l'heure de votre vérification.

Obtenir un nonce

Lorsque vous appelez l'API SafetyNet Attestation, vous devez transmettre un nonce. L'attestation obtenue contient ce nonce, ce qui vous permet de déterminer que l'attestation appartient à votre appel d'API et qu'elle n'est pas rejouée par un pirate informatique.

Un nonce utilisé avec une requête SafetyNet doit avoir une longueur d'au moins 16 octets. Vous devez introduire une variabilité dans votre nonce, afin que le même nonce ne soit jamais utilisé deux fois. Il est recommandé de déduire une partie du nonce à partir des données envoyées à vos serveurs. Par exemple, concaténez le hachage du nom d'utilisateur avec le code temporel de la requête pour former le nonce.

Important : Incluez autant de données que possible dans le nonce. De cette façon, les pirates informatiques auront plus de difficultés à lancer des attaques par rejeu. Par exemple, le fait de déduire le nonce du nom d'utilisateur limite les attaques par rejeu visant le même compte. Toutefois, la dérivation du nonce à partir de tous les détails d'un événement d'achat limite l'utilisation du message de réponse de l'API à cet événement d'achat uniquement.

Lorsque vous recevez la réponse signée de l'API, comparez toujours le nonce de la réponse signée à celui que vous reconstruisez à partir du reste du message envoyé à vos serveurs. Cette vérification garantit que les pirates informatiques ne peuvent pas réutiliser des attestations signées récupérées sur des appareils fiables pour d'autres requêtes malveillantes.

Pour en savoir plus sur l'utilisation des fonctions cryptographiques, consultez le guide sur l'utilisation de la cryptographie.

Demander l'attestation

Une fois que vous avez établi une connexion aux services Google Play et créé un nonce, vous êtes prêt à envoyer une requête d'attestation SafetyNet. La réponse à votre requête peut ne pas être immédiate. Il est donc préférable de configurer un écouteur de rappel pour gérer la réponse du service. Un exemple d'écouteur apparaît dans l'extrait de code suivant :

Kotlin

SafetyNet.getClient(this).attest(nonce, API_KEY)
    .addOnSuccessListener(this) {
        // Indicates communication with the service was successful.
        // Use response.getJwsResult() to get the result data.
    }
    .addOnFailureListener(this) { e ->
        // An error occurred while communicating with the service.
        if (e is ApiException) {
            // An error with the Google Play services API contains some
            // additional details.
            val apiException = e as ApiException

            // You can retrieve the status code using the
            // apiException.statusCode property.
        } else {
            // A different, unknown type of error occurred.
            Log.d(FragmentActivity.TAG, "Error: " + e.message)
        }
    }

Java

// The nonce should be at least 16 bytes in length.
// You must generate the value of API_KEY in the Google APIs dashboard.
SafetyNet.getClient(this).attest(nonce, API_KEY)
    .addOnSuccessListener(this,
        new OnSuccessListener<SafetyNetApi.AttestationResponse>() {
            @Override
            public void onSuccess(SafetyNetApi.AttestationResponse response) {
                // Indicates communication with the service was successful.
                // Use response.getJwsResult() to get the result data.
            }
        })
    .addOnFailureListener(this, new OnFailureListener() {
        @Override
        public void onFailure(@NonNull Exception e) {
            // An error occurred while communicating with the service.
            if (e instanceof ApiException) {
                // An error with the Google Play services API contains some
                // additional details.
                ApiException apiException = (ApiException) e;
                // You can retrieve the status code using the
                // apiException.getStatusCode() method.
            } else {
                // A different, unknown type of error occurred.
                Log.d(TAG, "Error: " + e.getMessage());
            }
        }
    });

La méthode onSuccess() indique que la communication avec le service a réussi, mais elle n'indique pas si l'appareil a réussi l'attestation SafetyNet. La section suivante explique comment lire le résultat de l'attestation et vérifier son intégrité.

Transférer la réponse d'attestation SafetyNet Attestation à votre serveur

Lorsque votre application communique avec SafetyNet, le service fournit une réponse contenant le résultat de l'attestation SafetyNet et inclut des informations supplémentaires pour vous aider à vérifier l'intégrité du message. Le résultat est fourni en tant qu'objet SafetyNetApi.AttestationResponse. Utilisez la méthode getJwsResult() de cet objet pour obtenir les données de la requête. La réponse est mise en forme en tant que signature Web JSON (JWS).

Renvoyez l'objet JWS à votre serveur pour validation et utilisation.

Utiliser la réponse d'attestation SafetyNet sur votre serveur

L'extrait JWS suivant montre le format et un exemple de contenu des données de charge utile :

{
  "timestampMs": 9860437986543,
  "nonce": "R2Rra24fVm5xa2Mg",
  "apkPackageName": "com.package.name.of.requesting.app",
  "apkCertificateDigestSha256": ["base64 encoded, SHA-256 hash of the
                                  certificate used to sign requesting app"],
  "ctsProfileMatch": true,
  "basicIntegrity": true,
  "evaluationType": "BASIC",
  "deprecationInformation": "..."
}

La charge utile d'une attestation signée contient généralement les champs suivants :

Code temporel de la réponse

timestampMs : millisecondes après l'epoch UNIX, lorsque le message de réponse JWS a été généré par les serveurs de Google.

Données fournies par l'application appelante

nonce : jeton à usage unique transmis par l'application appelante à l'API.

Données concernant l'application appelante

apkPackageName : nom de package de l'application appelante.
apkCertificateDigestSha256 : représentation(s) du hachage SHA-256 du ou des certificats de signature de l'application appelante, encodée(s) en base64.

Évaluation de l'intégrité

ctsProfileMatch : évaluation plus stricte de l'intégrité de l'appareil. Si la valeur de ctsProfileMatch est true, le profil de l'appareil exécutant votre application correspond à celui d'un appareil qui a réussi les tests de compatibilité Android et qui a été approuvé en tant qu'appareil Android certifié par Google.
basicIntegrity : évaluation plus permissive de l'intégrité de l'appareil. Si seule la valeur de basicIntegrity est true, cela signifie que l'appareil exécutant votre application n'a probablement pas été altéré. Toutefois, l'appareil n'a pas nécessairement réussi les tests de compatibilité Android.

Pour en savoir plus sur les tests de compatibilité Android, consultez les pages Concevoir un appareil Android et Suite de tests de compatibilité (CTS).

Remarque : Si vous n'avez pas besoin que l'appareil exécutant votre application réussisse les tests CTS, utilisez le paramètre basicIntegrity, car il permet à votre application de s'exécuter sur un plus large éventail d'appareils. Si votre application nécessite des garanties renforcées d'intégrité de l'appareil, vous ne devez utiliser que le résultat de ctsProfileMatch. Pour en savoir plus, consultez la section Évaluations potentielles de l'intégrité.
Attention : Vous ne devez faire confiance aux informations de l'APK que si la valeur de ctsProfileMatch est "true".

Informations sur l'abandon

deprecationInformation : chaîne contenant des informations destinées aux développeurs sur l'abandon de l'API SafetyNet Attestation.

Champs facultatifs

error : informations d'erreur encodées pertinentes pour la requête API actuelle.
advice : suggestion permettant de remettre un appareil dans un état favorable.
evaluationType : types de mesures ayant contribué à la réponse actuelle de l'API.

Évaluations potentielles de l'intégrité

Le message JWS contient deux paramètres qui indiquent le résultat de la vérification de la compatibilité des appareils : ctsProfileMatch et basicIntegrity. L'état de l'appareil exécutant votre application peut affecter la valeur de chaque paramètre, comme indiqué dans le tableau 1 :

Tableau 1. Exemples de la façon dont l'état de l'appareil peut affecter les valeurs de basicIntegrity et ctsProfileMatch

État de l'appareil	Valeur de `ctsProfileMatch`	Valeur de `basicIntegrity`
Appareil authentique certifié qui réussit les tests CTS	`true`	`true`
Appareil certifié avec bootloader déverrouillé	`false`	`true`
Appareil authentique mais non certifié (par exemple, lorsque le fabricant ne demande pas de certification)	`false`	`true`
Appareil avec ROM personnalisée (pas en mode root)	`false`	`true`
Émulateur	`false`	`false`
Aucun appareil (par exemple, un script d'émulation de protocole)	`false`	`false`
Signes de compromission de l'intégrité du système, qui peuvent comprendre le mode root	`false`	`false`
Signes d'autres attaques actives, comme des hooks d'API	`false`	`false`

Cas d'erreur

Le message JWS peut également afficher plusieurs types de conditions d'erreur :

Un résultat null indique que l'appel au service n'a pas abouti.
Un paramètre d'erreur dans JWS indique qu'un problème s'est produit, par exemple une erreur réseau ou une erreur simulée par un pirate informatique. La plupart des erreurs sont temporaires et devraient disparaître si vous effectuez un autre appel au service. Il peut être judicieux de réessayer plusieurs fois en augmentant les délais entre chaque tentative.
Si l'appareil est altéré, c'est-à-dire si "basicIntegrity" est défini sur "false" dans la réponse, l'évaluation peut ne pas contenir de données sur l'application appelante, telles que apkPackageName et apkCertificateDigestSha256. Cela se produit lorsque nos systèmes ne peuvent pas déterminer de manière fiable l'application appelante.

Que faire lorsque l'attestation signée signale une erreur ?

Réessayez. Les erreurs sur les appareils légitimes sont temporaires et devraient disparaître si vous effectuez un autre appel au service.
Vérifiez que votre application n'appelle pas l'API plus de cinq fois par minute sur les appareils concernés et que les quotas d'API de votre projet ne sont pas encore épuisés.
Supposons qu'il pourrait s'agir d'un pirate informatique déclenchant intentionnellement un cas d'erreur pour masquer son activité.

Conseils pour réussir les prochaines vérifications

Lorsqu'il est présent, le paramètre advice fournit des informations permettant d'expliquer pourquoi l'API SafetyNet Attestation a défini ctsProfileMatch ou basicIntegrity sur "false" dans un résultat particulier. La valeur du paramètre contient une liste de chaînes, comme celles de l'exemple suivant :

{"advice": "LOCK_BOOTLOADER,RESTORE_TO_FACTORY_ROM"}

Dans votre application, vous pouvez convertir les valeurs du paramètre de conseil en messages conviviaux pour aider l'utilisateur à réussir les futures attestations SafetyNet, comme indiqué dans la liste suivante :

LOCK_BOOTLOADER: L'utilisateur doit verrouiller le bootloader de son appareil.
RESTORE_TO_FACTORY_ROM: L'utilisateur doit restaurer la configuration ROM d'usine de son appareil.

Types d'évaluation

Le paramètre evaluationType est présent chaque fois que les évaluations ctsProfileMatch et basicIntegrity sont présentes.

Le paramètre fournit des informations sur les types de mesures utilisés pour calculer des champs tels que ctsProfileMatch et basicIntegrity pour une réponse particulière. La valeur du paramètre contient une liste de chaînes, comme dans l'exemple suivant :

{"evaluationType": "BASIC,HARDWARE_BACKED"}

Actuellement, les valeurs possibles sont les suivantes :

BASIC: Des mesures et des données de référence habituelles ont été utilisées.
HARDWARE_BACKED: Des fonctionnalités de sécurité intégrées au matériel ont été utilisées. Cela inclut des fonctionnalités telles qu'Attestation de clé, qui est pris en charge sur les appareils livrés avec Android 8.0 (niveau d'API 26) ou version ultérieure.

Dans votre application, vous pouvez traiter la présence de HARDWARE_BACKED dans le paramètre evaluationType comme un indicateur d'une meilleure évaluation de l'intégrité de l'appareil.

Remarque : S'appuyer sur le paramètre evaluationType est recommandé uniquement pour les applications qui utilisent déjà l'évaluation ctsProfileMatch et qui nécessitent le plus haut niveau de garanties d'intégrité de l'appareil, même si cela revient à limiter leur base d'utilisateurs. Dans la plupart des cas, vous devez continuer à vous appuyer sur les évaluations basicIntegrity et ctsProfileMatch pour détecter les utilisations abusives. Ces évaluations comprennent déjà des fonctionnalités de sécurité intégrées au matériel, le cas échéant.

Si vous décidez de dépendre de la présence d'une certaine valeur dans le paramètre evaluationType, vous devez envisager d'implémenter un mécanisme de nouvelle tentative dans votre application au cas où des erreurs temporaires se produiraient.

Vérifier la réponse d'attestation SafetyNet

Vous devez prendre des mesures pour vous assurer que la réponse d'attestation SafetyNet provient bien du service SafetyNet et inclut les données correspondant à votre requête.

Pour vérifier l'origine du message JWS, procédez comme suit :

Extrayez la chaîne de certificats SSL du message JWS.
Validez la chaîne de certificats SSL et utilisez la correspondance des noms d'hôte SSL pour vérifier que le certificat d'entité finale a été délivré pour le nom d'hôte attest.android.com.
Utilisez le certificat pour vérifier la signature du message JWS.
Vérifiez les données du message JWS pour vous assurer qu'elles correspondent à celles de votre requête d'origine. Assurez-vous en particulier que le code temporel a été validé et que le nonce, le nom du package et les hachages du ou des certificats de signature de l'application correspondent aux valeurs attendues.

Vous devez vérifier l'instruction JWS à l'aide de solutions cryptographiques standards, telles que celles décrites dans l'exemple d'utilisation de l'API android-play-safetynet, disponible sur GitHub.

Lors des tests et du développement initiaux (mais pas en production), vous pouvez appeler une API en ligne pour vérifier la signature de l'instruction JWS. Ce processus a également été illustré dans l'exemple d'API android-play-safetynet disponible sur GitHub. Notez que l'API de vérification en ligne est uniquement destinée aux tests préliminaires. Vous disposez d'un quota fixe de 10 000 requêtes par jour.

Important : L'utilisation de l'API de vérification en ligne permet uniquement de valider que le message JWS a été signé par les serveurs de l'API SafetyNet Attestation. Cette API en ligne ne peut pas vérifier si les champs de la charge utile correspondent aux valeurs attendues par votre service.

Prévoir les situations inattendues

Nous vous recommandons de planifier votre utilisation de manière à tenir compte des modifications et des pannes.

Modifications apportées à l'API

De nouveaux champs (expérimentaux) peuvent apparaître dans l'évaluation à tout moment. Assurez-vous que ces champs supplémentaires n'entravent pas votre analyseur ni votre logique d'utilisation. En particulier, ne vous fiez pas aux champs expérimentaux avant qu'ils ne soient annoncés dans la liste de diffusion des clients de l'API SafetyNet.

L'API SafetyNet Attestation est indisponible

Dans le cas peu probable où l'API SafetyNet Attestation serait indisponible, il sera vivement recommandé aux utilisateurs de cette API de développer des fonctionnalités côté serveur afin de contrôler dynamiquement la dépendance envers la disponibilité et la qualité de cette API et de sa réponse.

Les stratégies typiques doivent inclure la possibilité de demander de manière dynamique à vos applications d'arrêter d'appeler cette API, ainsi que des listes d'autorisation basées sur les appareils et les utilisateurs pour ignorer les résultats de l'API SafetyNet Attestation pour certaines classes d'appareils et d'utilisateurs.

Exemple de code

Pour obtenir des conseils supplémentaires sur l'utilisation des API SafetyNet, consultez l'exemple de code disponible sur GitHub.

Liste des annonces

Nous vous recommandons vivement de rejoindre la liste de diffusion des clients de l'API SafetyNet pour recevoir les dernières informations sur l'API SafetyNet Attestation.

Commentaires

N'hésitez pas à nous faire part de vos commentaires sur cette API. Nous nous appuyons sur vos commentaires pour déterminer le niveau de priorité des nouvelles fonctionnalités de cette API.

En savoir plus

Pour en savoir plus sur les bonnes pratiques d'utilisation de l'API SafetyNet Attestation, consultez les liens suivants :

Conditions d'utilisation supplémentaires

En accédant aux API SafetyNet ou en les utilisant, vous acceptez les conditions d'utilisation des API Google et les présentes conditions supplémentaires. Veuillez lire attentivement l'ensemble des conditions d'utilisation et des règles applicables avant d'accéder aux API.

Conditions d'utilisation de SafetyNet

Comme pour toutes les données collectées en grande quantité à partir d'une observation sur le terrain, il existe un risque de faux positifs et de faux négatifs. Ces données s'entendent au meilleur de notre compréhension. Nous testons de manière approfondie nos mécanismes de détection pour en garantir la précision, et nous nous engageons à améliorer ces méthodes au fil du temps pour qu'elles restent précises.

Vous acceptez de respecter les lois, réglementations et droits de tiers applicables (y compris, sans s'y limiter, les lois concernant l'importation ou l'exportation de données ou de logiciels, la confidentialité et les lois locales). Vous ne devez pas utiliser les API pour encourager ou promouvoir des activités illégales ou une violation des droits de tiers. Vous n'enfreindrez aucune autre condition d'utilisation de Google (ou de ses sociétés affiliées).

Vous reconnaissez et comprenez que le fonctionnement de l'API SafetyNet consiste à collecter des informations matérielles et logicielles, telles que des données sur les appareils et les applications ainsi que les résultats des attestations SafetyNet, puis à envoyer ces données à Google pour analyse. En vertu de la section 3(d) des conditions d'utilisation des API Google, si vous utilisez les API, vous acceptez qu'il vous incombe d'en informer les utilisateurs et de leur demander leur autorisation pour la collecte et le partage de ces données avec Google.

Sécurité des données d'attestation SafetyNet

Google Play dispose d'une section sur Sécurité des données qui permet aux développeurs de divulguer les approches adoptées dans leurs applications concernant la collecte, le partage et la sécurité des données. Pour vous aider à répondre aux exigences de la section Sécurité des données, vous pouvez utiliser les informations suivantes concernant la manière dont l'API SafetyNet Attestation traite les données :

Type de pratique	Comment l'API SafetyNet Attestation applique la pratique
Collecte des données sur l'utilisation	Nom du package Certificat de signature d'application Jeton d'attestation d'appareil généré par les services Google Play
Rôle de la collecte de données	Les données collectées sont utilisées pour vérifier l'intégrité de l'application et de l'appareil.
Chiffrement des données	Les données ne sont pas chiffrées.
Partage des données	Les données ne sont pas transférées à des tiers.
Suppression des données	Les données sont supprimées après une durée de conservation déterminée à l'avance.

Pour créer votre communiqué sur les données, vous pouvez consulter le guide sur les types de données d'Android afin de déterminer quels types de données décrivent le mieux les données collectées. Dans votre communiqué, veillez également à prendre en compte comment votre application spécifique partage et utilise les données collectées.

Notre objectif est d'être les plus transparents possible. Toutefois, nous ne pouvons pas parler en votre nom et vous êtes seul responsable de vos réponses au formulaire de Google Play pour la section Sécurité des données concernant la collecte et le partage des données utilisateur dans votre application, ainsi que vos pratiques de sécurité.