IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Les applications Google Dialer et Messages auraient discrètement envoyé des informations sur les appels et les textes à Google,
Journaux d'appels téléphoniques collectés sans option de refus

Le , par Bruno

295PARTAGES

4  0 
Selon un document de recherche intitulé What Data Do The Google Dialer and Messages Apps On Android Send to Google ?, produit par Douglas Leith, professeur d'informatique au Trinity College de Dublin, Google Messages (pour la messagerie texte) et Google Dialer (pour les appels téléphoniques) ont envoyé des données sur les communications des utilisateurs au service d'enregistrement Clearcut de Google Play Services et au service Firebase Analytics de Google.

« Nous rapportons des mesures des données envoyées à Google par les applications Google Messages et Google Dialer sur un téléphone Android. Nous constatons que ces applications indiquent à Google quand un message ou un appel téléphonique est émis/reçus. Les données envoyées par Google Messages incluent un hachage du texte du message, permettant de relier l'expéditeur et le destinataire dans un échange de messages. Les données envoyées par Google Dialer comprennent l'heure et la durée de l'appel, ce qui permet là encore de relier les deux combinés engagés dans un appel téléphonique. Les numéros de téléphone sont également envoyés à Google », précise le rapport d’étude.


Les applications Messages et Dialer de Google pour les appareils Android auraient collecté et envoyé des données à Google sans préavis ni consentement spécifique, et sans offrir la possibilité de refuser, ce qui constitue une violation potentielle de la loi européenne sur la protection des données. Le moment et la durée des autres interactions des utilisateurs avec ces apps ont également été transmis à Google. Et Google n'offre aucun moyen de refuser cette collecte de données.

Google Messages (com.google.android.apps.messaging) est installé sur plus d'un milliard de combinés Android. Il est proposé par AT&T et T-Mobile sur les téléphones Android aux États-Unis et est préchargé sur les téléphones récents de Huawei, Samsung et Xiaomi. De même, Google Dialer (également connu sous le nom de Phone by Google, com.google.android.dialer) a la même portée.

Selon le document, les deux versions préinstallées de ces applications ne comportent pas de règles de confidentialité spécifiques expliquant quelles données sont collectées, ce que Google exige des développeurs tiers. Et lorsqu'une demande a été faite via Google Takeout pour les données du compte Google associées aux applications utilisées pour les tests, les données fournies par Google ne comprenaient pas les données de télémétrie observées.

Les deux applications ont actuellement des liens sur Google Play vers les règles de confidentialité de Google pour les consommateurs, qui ne sont pas spécifiques à l'application et ne sont pas nécessairement évidentes pour ceux qui reçoivent les applications préinstallées. À partir de l'application Messages, Google prend le contenu du message et un horodatage, génère un hachage SHA256, qui est la sortie d'un algorithme qui fait correspondre le contenu lisible par l'homme à un condensé alphanumérique, puis transmet une partie du hachage, plus précisément une valeur tronquée de 128 bits, à l'enregistreur Clearcut de Google et à Firebase Analytics.

Les hachages sont conçus pour être difficiles à inverser, mais dans le cas de messages courts, Leith a déclaré qu'il pense que certains d'entre eux pourraient être défaits pour récupérer une partie du contenu du message.

« Des collègues me disent que oui, en principe, cela est possible », a déclaré Leith dans un courriel adressé à une agence de communication. « Le hachage comprend un horodatage horaire, ce qui impliquerait de générer des hachages pour toutes les combinaisons d'horodatages et de messages cibles et de les comparer au hachage observé pour trouver une correspondance. Ce qui est faisable, je pense, pour les messages courts compte tenu de la puissance de calcul moderne. »


L'application Dialer enregistre également les appels entrants et sortants, ainsi que l'heure et la durée de l'appel. Comme le précise le document, Google Play Services indique que certaines données sont collectées à des fins de sécurité et de prévention des fraudes, pour assurer la maintenance des API et des services de base de Google Play Services et pour fournir des services Google tels que la synchronisation des signets et des contacts. Cependant, il ne détaille ni n'explique sa collecte du contenu des messages ou des appelants et des destinataires des appels. Comme le dit le document, « peu de détails sont donnés sur les données réellement collectées. »

« J'ai été surpris de voir que ces données étaient collectées par ces applications Google », a déclaré Leith. Leith a fait part de ses découvertes à Google en novembre dernier et a déclaré avoir eu plusieurs conversations avec le directeur technique de Google pour Google Messages au sujet des changements suggérés.
Le document décrit neuf recommandations formulées par Leith et six modifications que Google a déjà apportées ou prévoit d'apporter pour répondre aux préoccupations soulevées dans le document. Les modifications que Google a acceptées sont les suivantes :

  • la révision du flux d'intégration des applications afin que les utilisateurs soient informés qu'ils utilisent une application Google et qu'un lien vers les règles de confidentialité de Google à l'intention des consommateurs leur soit présenté ;
  • l'arrêt de la collecte du numéro de téléphone de l'expéditeur par la source de journalisation CARRIER_SERVICES, du 5 SIM ICCID et d'un hachage du texte des messages envoyés/reçus par Google Messages ;
  • arrêt de l'enregistrement des événements liés aux appels dans Firebase Analytics à partir de Google Dialer et Messages ;
  • la collecte de davantage de données télémétriques pour utiliser l'identifiant le moins durable possible, plutôt que de le lier à l'identifiant Android persistant de l'utilisateur ;
  • Indiquer clairement quand l'identification de l'appelant et la protection contre le spam sont activées et comment elles peuvent être désactivées, tout en examinant la possibilité d'utiliser moins d'informations ou des informations floues pour les fonctions de sécurité.

Google aurait confirmé lundi que les représentations du journal concernant ses interactions avec Leith sont exactes. « Nous accueillons favorablement les partenariats et les commentaires des universitaires et des chercheurs, y compris ceux du Trinity College », a déclaré un porte-parole de Google. « Nous avons travaillé de manière constructive avec cette équipe pour répondre à ses commentaires, et nous continuerons à le faire. »

Le document soulève des questions sur la conformité des apps de Google avec le RGPD, mais prévient que les conclusions juridiques sont hors de portée pour ce qui est une analyse technique. Selon Leith, il n'est pas certain que les engagements de Google répondent pleinement aux préoccupations qu'il a soulevées.

« Nous rendons compte ici d'une étude technique, pas d'une étude juridique, et de toute façon, nous ne sommes pas qualifiés juridiquement. Néanmoins, la collecte de données que nous observons chez Google soulève des questions évidentes concernant la réglementation sur la protection des données RGPD en Europe », précise l’étude.

Il existe trois principaux fondements de la collecte de données en vertu du RGPD :

  • les données sont anonymes, c'est-à-dire qu'elles ne peuvent raisonnablement être liées à une personne et ne sont donc pas des données à caractère personnel ;
  • avec le consentement de l'intéressé, dans un but défini et pour le compte de l'autorité compétente ;
  • pour les intérêts légitimes de Google.

  1. Absence d'anonymat : En ce qui concerne l'anonymat, tous les événements enregistrés par l'enregistreur Clearcut de Google Play Services sont étiquetés avec l'identifiant Android de l'appareil. Via d'autres données collectées par Google Play Services, cet identifiant est lié :

    1. Au numéro de série de l'appareil ;
    2. Au numéro de série du téléphone ;
    3. À l'IMEI de la carte SIM (qui identifie l'emplacement de la carte SIM) ;
    4. Au compte Google de l'utilisateur.

    Lorsqu'une carte SIM est insérée, l'application Google Messages associe également l'identifiant Android au numéro de série/ICCID de la carte SIM, qui identifie de manière unique la carte SIM. En faisant une demande à l'aide de "https://takeout.google.com/" pour les données associées au compte d'utilisateur Google utilisé dans les essais l’équipe a également confirmé que les données rapportées sous la rubrique Android Device Configuration Service comprennent l'identifiant Android ID pour chaque combiné utilisé (ainsi que le numéro de série du combiné, SIM IMEI, la dernière adresse IP utilisée et les détails de l'opérateur mobile).

    Lors de la création d'un compte Google, il est nécessaire de fournir un numéro de téléphone sur lequel un texte de vérification peut être reçu. Pour de nombreuses personnes, il s'agira de leur propre numéro de téléphone. L'utilisation des services Google, par exemple l'achat d'une application payante sur la boutique Google Play ou l'utilisation de Google Pay ou l'utilisation de Google Pay permet de lier le compte Google d'une personne à sa carte de crédit ou à ses coordonnées bancaires. Le compte Google d'un utilisateur et donc l'Android ID, peut donc généralement être lié à l'identité réelle de l'utilisateur.

    En outre, lorsqu'un message est reçu par l'application Google Messages, le numéro de téléphone de l'expéditeur est envoyé à Google par le biais de l'enregistreur Clearcut de Google Play Services. En combinant les données de la paire de combinés impliqués dans l'échange de messages (ce qui semble parfaitement faisable au vu des hachages du texte des messages que nous observons être envoyés à Google) les deux numéros de téléphone peuvent être révélés et liés aux identifiants Android.

    De même, lorsque l'option de protection contre le spam est activée dans le composeur de Google (comme c'est le cas par défaut). Tous les événements enregistrés par Google Analytics sont marqués par l'identifiant publicitaire Google de l'utilisateur. l'ID Google Advertising de l'utilisateur et l'ID Firebase de l'application expéditrice. Firebase ID de l'expéditeur. L'identifiant Firebase de l'application est directement lié à l'identifiant Android de l'appareil Android lorsque l'application s'inscrit pour utiliser le service Google Analytics.
  2. Absence de consentement : le consentement spécifique n'a pas été demandé ni donné pour la collecte de données par les applications Google Messages et Dialer, et il n'y a pas d'option de retrait ;
  3. Intérêt légitime : l'invocation de l'intérêt légitime requiert que les données soient collectées pour une finalité spécifique, que les données soient nécessaires à cette finalité, que la collecte des données soit mise en balance contre les intérêts et les libertés de la personne, etc.

La base de l'intérêt légitime pour la collecte des données est la moins claire, et il est probablement préférable de le laisser aux juristes. Notons cependant qu’aucune politique de confidentialité spécifique à une application indiquant le but spécifique pour lequel les données observées sont collectées n’a été trouvée.

Il est généralement simple d'observer les paquets envoyés depuis un téléphone mobile. Les chercheurs ont configuré les combinés étudiés pour qu'ils utilisent une connexion WiFi à un point d'accès contrôlé, sur lequel ils utilisent tcpdump pour capturer le trafic sortant. Cependant, ceci est peu utile pour l'analyse de la vie privée car :
  • les charges utiles des paquets sont presque toujours chiffrées en raison de l'utilisation généralisée de HTTPS pour transférer des données ;
  • avant le chiffrement des messages, les données sont souvent codées dans un format binaire pour lequel il existe peu ou pas de documentation publique.


  1. Décryptage des connexions HTTPS

    Presque toutes les données observées sont envoyées par des connexions HTTPS et sont donc chiffrées à l'aide de TLS/SSL (en plus de tout autre chiffrement utilisé par l'application). Cependant, le déchiffrement des connexions SSL est relativement simple. L’équipe achemine le trafic du combiné par un point d'accès WiFi (AP) qu’ils contrôlent, ils configureront ce point d'accès pour qu'il utilise mitmdump en tant que proxy et ajuste le niveau de sécurité.

    Le combiné mobile est configuré pour accéder à l'Internet en utilisant un point d'accès WiFi hébergé sur un Raspberry Pi. Un certificat système est installé sur le téléphone pour être capable de déchiffrer le trafic sortant. Le point d'accès prétend à tout processus s'exécutant sur le téléphone d'être le serveur de destination, crée une connexion avec la cible réelle et relaie les demandes et leurs réponses entre le combiné et le serveur tout en enregistrant le trafic.
    Les paramètres du pare-feu redirigent tout le trafic HTTP/HTTPS du WiFi vers mitmdump afin que le proxy soit transparent pour le combiné.

    Lorsqu'un processus s'exécutant sur le combiné démarre une nouvelle connexion réseau, le proxy mitmdump se fait passer pour le serveur de destination et présente un faux certificat pour le serveur cible. Ce qui permet à mitmdump de déchiffrer le trafic. Il crée ensuite une connexion vers le serveur cible réel et agit comme un intermédiaire, relayant les demandes et leurs réponses entre le serveur cible tout en enregistrant le trafic.

    Les processus système effectuent généralement des contrôles de l'authenticité des certificats de serveur reçus lors du démarrage d'une nouvelle connexion et interrompent la connexion lorsque ces contrôles ne sont pas satisfaisants. Pour les applications et services Google, l'installation du certificat CA mitmproxy en tant que certificat de confiance permet de faire passer ces contrôles. L'installation d'un certificat de confiance est légèrement compliquée dans Android 10 et ultérieur, car la partition du disque système, sur laquelle les certificats de confiance sont stockés, est en lecture seule et les mesures de sécurité empêchent de la monter en lecture-écriture.

    Heureusement, les dossiers de la partition du disque système peuvent être remplacés en créant un nouveau point de montage correspondant au dossier. De cette façon, le certificat CA de mitmdump peut être ajouté au répertoire /system/etc/security/cacerts.
  2. Télémétrie des services Google Play

    Les applications Google Message et Dialer n'envoient pas de données directement à Google, mais envoient plutôt des données aux services d'enregistrement d'événements au sein de Google Play Services. Plus précisément, au service de journalisation Clearcut et le service Google/Firebase Analytics.

    Ces composants des services Google Play exposent des API que l'application utilise pour communiquer avec eux. Les services Clearcut logger et services Google/Firebase Analytics regroupent ensuite les données reçues et les transmettent aux serveurs de Google. L'enregistreur Clearcut envoie les données à ''https://play.googleapis.com/log/batch'' tandis que Google/-Firebase Analytics envoie les données à "https://app-measurement.com/".

    Les services Clearcut logger et Google/Firebase Analytics codent les données dans différents formats pour les envoyer à Google. Les chercheurs examinent alors ces formats plus en détail.
  3. Décodage des données du collecteur Clearcut des services Google Play

    Le service de journalisation Clearcut des services Google Play envoie des données à ''https://play.googleapis.com/log/batch''. Chaque message envoyé comprend un cookie NID et un jeton d'authentification x-server-token (qui servent d'identifiants de périphérique), suivis du corps du message, par exemple

Code : Sélectionner tout
POST https://play.googleapis.com/log/batch Headers x-server-token: CAESOQDyi0h8...YWXxG0vLQ cookie: NID=511=Oy6F1KJ7JeZ...yZ0RhdX8o6efg


Notons que la séquence des entrées de journal envoyée par chaque source de journal est codée comme un tableau protobuf. C'est-à-dire, comme une séquence d'entrées à partir de laquelle les protobufs des entrées de journal individuelles doivent être extraits et décodés. Les outils standards ne peuvent pas décoder un tableau de protobuf mais les chercheurs ont mis à la disposition du public des outils logiciels qu’ils ont développés pour cela.

Les protobufs peuvent être décodés sans connaître le contenu du message en utilisant le compilateur Google Protobuf avec l'option --decode_raw. Cependant, cela signifie que l'interprétation des valeurs est manquante et il y a aussi parfois ambiguïté quant à l'interprétation des types de valeurs. Le corps du message est codé dans un format binaire protobuf.

« Nous rendons compte des mesures des données envoyées à Google par les apps Google Messages et Google Dialer sur un téléphone Android. Nous constatons que ces applications indiquent à Google quand un message ou un appel téléphonique est émis ou reçu. », précise Douglas Leith, professeur d'informatique au Trinity College de Dublin. Les données envoyées par Google Messages comprennent un hachage du texte du message, ce qui permet d'établir un lien entre l'expéditeur et le destinataire dans un échange de messages, et par Google Dialer, l'heure et la durée de l'appel, ce qui permet également de relier les deux combinés engagés dans un appel téléphonique.

Les numéros de téléphone sont également envoyés à Google. En outre, l'heure et la durée des interactions de l'utilisateur avec les applications sont envoyées à Google. Il n'y a pas d'exclusion de cette collecte de données. Les données sont envoyées par deux canaux, les services Google Play

  1. L'enregistreur Clearcut ;
  2. Google/Firebase Analytics.

Cette étude est l'une des premières à faire la lumière sur les données télémétriques réelles envoyées par Google Play Services qui étaient jusqu'à présent largement opaques.

Source : Trinity College de Dublin

Et vous :

Quel est votre avis sur les résultats de cette étude ?

Voir aussi :

86 % des comptes Google Cloud piratés sont utilisés pour du cryptomining illégal, les autres attaques consistant à effectuer un balayage des ports d'autres cibles sur Internet, selon AtlasVPN

Google fermera les comptes G Suite gratuits si le titulaire du compte ne passe pas à un compte payant, les utilisateurs ont jusqu'au mois de mai pour passer à la caisse

Google acquiert la société de cybersécurité Mandiant pour 5,4 milliards de dollars, pour renforcer son activité de cloud computing et consolider ses opérations de sécurité et services de conseil

« Google a fermé mon compte pour avoir partagé des archives historiques qu'ils ont qualifiées "d'activité terroriste" », un éditeur indique qu'il risque de perdre des années de recherches

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de escartefigue
Modérateur https://www.developpez.com
Le 24/03/2022 à 8:53
Citation Envoyé par TotoParis Voir le message
Là, on est directement dans l'espionnage de masse à l'échelle mondiale. Mais Google c'est le Camp du Bien...
Citation Envoyé par TotoParis Voir le message
Vous êtes méchant avec Joe Biden ! C'est le Camp du Bien quand même !
Tenez, lisez ce qui vous attend :
https://insolentiae.com/biden-il-va-...harles-sannat/
Citation Envoyé par TotoParis Voir le message
J'allais dire un très gros mot mais je me suis retenu. Et ne suis pas surpris. Tesla, c'est le Camp du Bien quand même...
Et à part ça ?
2  0 
Avatar de TotoParis
Membre expérimenté https://www.developpez.com
Le 23/03/2022 à 17:06
Là, on est directement dans l'espionnage de masse à l'échelle mondiale. Mais Google c'est le Camp du Bien...
1  3