De la difficulté technique de l’anonymisation, ou comment mal anonymiser ses données
Des techniques d’anonymisation sont appliquées depuis de nombreuses années¹ pour différents cas d’usages, notamment la protection de jeux ne nécessitant pas l’exactitude des données ou la publication de données à un large public (open data, concours de data science…). Aujourd’hui, avec l’entrée en vigueur du RGPD, le sujet prend encore plus d’ampleur², beaucoup d’acteurs voyant dans l’anonymisation une obligation du règlement ou, plus justement, une possibilité de soustraire certains jeux de données à son périmètre d’application³.
Or ceux qui s’engagent dans la voie de l’anonymisation de données butent souvent sur une quantité insoupçonnée de difficultés, notamment l’immaturité du marché des solutions, le manque de compétences et enfin la difficulté technique de l’anonymisation — efficace — de données. Dans un précédent article⁴ nous avons détaillé ces trois difficultés, mais nous allons approfondir ici la difficulté technique de l’anonymisation, souvent sous-estimée.
L’enjeu de l’anonymisation de données est une obligation de résultat
Le problème de l’anonymisation de données, quel que soit l’objectif poursuivi par l’acteur qui l’effectue, s’apparente à un problème d’obligation de résultat. En effet, ce qui compte, c’est la possibilité de réidentifier des personnes sur le jeu anonymisé : si cela est impossible, le jeu est bien anonymisé ; si cela est possible, le jeu est mal anonymisé.
Les esprits les plus aiguisés parmi vous voient déjà poindre une particularité : seul le résultat négatif est démontrable. En d’autres termes, il est très difficile de démontrer qu’un jeu de données est bien anonymisé, alors que pour démontrer qu’un jeu est mal anonymisé, il suffit de parvenir à réidentifier quelqu’un.
Prenons un exemple concret. Le gestionnaire de la flotte de véhicules de fonction d’une entreprise souhaite établir une corrélation entre l’aspect esthétique du véhicule et la propension à recevoir une amende (pourquoi pas ?). Devant présenter ses résultats à la direction et ne voulant pas incriminer nominativement les salariés, il enlève le nom et le prénom de la liste, et présente simplement le modèle de véhicule et le nombre d’infractions commises. Salarié de l’entreprise, Jean-Michel met la main sur cette liste et il est convaincu que son beau-frère détesté, également salarié, est un pirate de la route : il aimerait bien le dénoncer publiquement. Or il sait qu’il conduit une Twingo couleur pistache… Et il n’y a qu’une Twingo couleur pistache dans la liste… Bingo !
Par cet exemple simpliste, nous voyons deux choses :
- vous pouvez considérer votre jeu comme anonyme autant que vous voulez, jusqu’à ce que quelqu’un ait réussi à réidentifier une personne ;
- avec un degré de connaissance externe suffisant et une bonne débrouillardise, il est très souvent possible de réidentifier une personne.
Et en effet, les attaquants qui réidentifient des personnes dans un jeu anonyme y parviennent la plupart du temps grâce à des informations, souvent publiques et facilement accessibles, externes à l’organisme responsable du jeu anonymisé, donc hors de son contrôle.
Bien sûr, des techniques d’anonymisation avancées permettent d’éviter certaines failles basiques comme la précédente (résolue par la k-anonymité, qui impose dans une classe d’équivalence — ici la valeur du couple (modèle ; couleur) — une quantité minimum — k — d’occurrences). Mais d’autre part, les attaquants peuvent disposer de bien plus d’informations (comme des informations publiques, dont celles disponibles sur les réseaux sociaux) et d’outils d’analyse bien plus performants (comme un ordinateur standard et un cerveau) que Jean-Michel. Car, au-delà de la qualité de l’anonymisation en elle-même, c’est sur ces deux piliers que repose la capacité de réidentification d’un attaquant :
- les outils d’analyse mathématique et de rétro-ingénierie applicables sur le jeu de données ;
- la masse d’informations publiquement disponible sur tout individu ou les autres jeux de données privés que l’attaquant aurait à disposition.
Qu’en disent les autorités ? Mesurez le risque de réidentification !
Certes, le RGPD, qui indique que seules les données qui ne peuvent plus permettre de retrouver la personne concernée sont considérées comme anonymes et donc sortent du périmètre du même règlement, précise que :
« pour déterminer si une personne physique est identifiable, il convient de prendre en considération l’ensemble des moyens raisonnablement susceptibles d’être utilisés par le responsable du traitement ou par toute autre personne pour identifier la personne physique directement ou indirectement, […] [en prenant] en considération l’ensemble des facteurs objectifs, tels que le coût de l’identification et le temps nécessaire à celle-ci, en tenant compte des technologies disponibles au moment du traitement et de l’évolution de celles-ci. »⁵
L’on doit comprendre que bien sûr, avec une puissance de calcul infinie et l’accès à une grande quantité d’informations complémentaires, il sera presque toujours possible de réidentifier des personnes sur un jeu anonymisé, et qu’il convient donc de prendre en considération ce qui est « raisonnablement » envisageable par un attaquant, seul ou en organisation, disposant de technologies modernes.
Afin d’interpréter ce vague « raisonnablement » indiqué par le RGPD, l’on peut s’appuyer sur des travaux antérieurs du Groupe de travail Article 29 (G29) qui propose, dans un avis⁶ de 2014 sur les techniques d’anonymisation, la notion de risque de réidentification. Il existe selon le G29 trois critères pour évaluer la qualité d’une anonymisation :
- L’individualisation : est-il possible d’isoler un individu ?
- La corrélation : est-il possible de relier entre eux des ensembles de données distincts concernant un même individu ?
- L’inférence : est-il possible de déduire de l’information sur un individu à partir des données disponibles ?
Malgré cette clarification apportée par le G29, le travail d’estimation du risque de réidentification selon ces trois critères reste très difficile pour la plupart des sociétés, étant donné qu’il nécessite un mélange de maîtrise de l’environnement métier, de connaissances techniques, de connaissances sur la théorie de l’information et sur la cybersécurité en général, notamment pour tenir compte de tous les risques externes à l’entreprise.
Comment mal anonymiser ses données ?
Tout cela restant très théorique, essayons d’illustrer des anonymisations manifestement de mauvaise qualité par les exemples suivants.
Confondre anonymisation, pseudonymisation et effacement
Nous avons consacré à cette confusion un article⁷, que nous tentons de résumer ici par deux tableaux synthétiques.
Ici la donnée est effacée. Elle n’a comme intérêt éventuel que de conserver certaines règles de formatage (date valide pour Date de naissance et alphabétique pour Nom et Prénom), mais toutes signifiance métier ou distribution de valeurs sont perdues (toutes les lignes sont anonymisées de la même façon et cela aura peu d’intérêt pour des tests applicatifs, par exemple pour voir si le « ç » s’affiche correctement dans l’IHM).
Ici elle est pseudonymisée. En effet, je conserve une colonne pivot qui me permet, réversiblement, de retrouver les données d’origine. Ceci n’est pas considéré par le RGPD comme une anonymisation, car cette dernière doit être irréversible pour être valable. Si je supprime la table pivot, par contre, cela équivaut à un effacement ou une anonymisation, en fonction de la technique utilisée.
Effacer simplement les données directement identifiantes
Supprimer les données directement identifiantes (nom et prénom, numéro de sécurité sociale, adresse mél…) suffit rarement à anonymiser efficacement un jeu de données.
Ici je conserve la date de naissance exacte. Si je connais la date de naissance de Charles Pascual, je peux déduire avec une forte probabilité que cette ligne le concerne (individualisation).
Anonymiser un jeu de petite taille
Tous les jeux de données ne permettent pas d’appliquer efficacement toutes les techniques : il faut suffisamment de données, suffisamment variées pour que l’anonymisation soit efficace. Par exemple, anonymiser un jeu de données portant sur les salariés d’une entreprise de… 10 personnes ne sert à rien, quelle que soit la méthode choisie.
J’introduis ici une incertitude au niveau de la date de naissance. Mais si la valeur est suffisamment isolée dans la distribution (comprendre : dans le jeu de données ils sont peu nombreux à avoir environ 34 ans, la grande majorité ont plutôt plus de 40 ou plutôt moins de 30), je peux déduire avec une forte probabilité que cette ligne le concerne (individualisation).
Anonymiser par une technique déterministe
Dans ce cas on atteint un cas limite de l’anonymisation. En effet, l’énorme majorité des techniques d’anonymisation, pour ne pas dire toutes, sont déterministes, c’est-à-dire qu’à entrée égale correspond sortie égale. La plupart des techniques d’anonymisation sont déterministes car cela permet de conserver une cohérence au sein des systèmes. Par exemple, si mon modèle de données possède plusieurs tables avec des relations, il faut que la clé primaire d’une table et son équivalent en clé étrangère d’une autre table liée soient anonymisées de la même façon, afin que la relation soit préservée dans le jeu anonymisé. Dans d’autres cas, on voudra rafraîchir des jeux de données anonymisés très massifs en ne ré-anonymisant que les données modifiées depuis la dernière anonymisation : alors on voudra que les données soient anonymisées de la même façon afin que les lignes rafraîchies ne soient pas incohérentes avec les lignes inchangées. Ce ne sont ici que deux exemples des raisons pour lesquelles l’on préfère souvent une anonymisation déterministe.
Ici on utilise un dictionnaire pour anonymiser Nom et Prénom. Or, même si je n’ai aucune idée de la date de naissance de Charles Pascual, il y a certains cas où je peux déduire que Charles Pascual est anonymisé systématiquement en Jean Dupond :
- J’ai des informations sur Charles Pascual qui me permettent de l’identifier sur une autre occurrence ou une autre table anonymisées, ce qui me permet de savoir que Charles Pascual correspond à Jean Dupond et donc de décrypter cette table et déduire sa date de naissance (corrélation).
- J’ai accès à la fonction d’anonymisation en boîte noire, et par une attaque en force brute je retrouve la ou les entrées correspondant à la sortie Jean Dupond (individualisation).
Ces considérations restent bien évidemment valables sur tout autre attribut que nom-prénom.
De nombreux autres exemples pourraient être donnés, mais déjà ceux-ci permettent de souligner qu’il faut porter une grande attention non seulement à l’ensemble des attributs d’un enregistrement et à leur corrélation, mais également aux différents enregistrements concernant le même individu, ainsi qu’à certaines propriétés de l’enregistrement par rapport au jeu de données auquel il appartient voire du jeu de données lui-même dans sa globalité. Il n’est pas possible de définir des règles générales absolues sur ce qu’est une bonne anonymisation, si ce n’est en disant, comme l’avis du G29, qu’elle doit résister à différents types d’attaques. En outre, la qualité d’une anonymisation dépend fortement de la forme du jeu de données qu’on est en train de traiter.
Des attaquants ou des maladroits ?
L’on parle beaucoup d’attaquant, car il faut considérer que si on anonymise des données, c’est surtout pour limiter l’impact sur la vie privée des personnes concernées en cas de fuite ou vol de données. Néanmoins, un cas d’usage important de l’anonymisation consiste simplement à anonymiser les données utilisées lors des tests applicatifs ou dans les analyses marketing de masse. Dans ce cas, tant que ce ne sont que les salariés de l’entreprise qui y ont accès, on peut considérer qu’ils n’auront pas de mauvaises intentions. Mais ces considérations de bon sens n’enlèvent rien aux exigences des autorités envers la qualité d’une anonymisation, et n’oublions pas que des salariés peuvent également faire preuve de maladresse voire de malveillance.
La réidentification dans la vraie vie
Toutes ces considérations ne sont pas purs délires paranoïaques. Outre le fait que la CNIL a déjà pris des mesures contre des sociétés ayant un processus d’anonymisation inefficace⁸, la qualité de l’anonymisation a également été remise en cause dans la pratique par des attaques de réidentification, souvent, heureusement, de la part de journalistes, blogueurs, scientifiques et autres lanceurs d’alertes. Analysons ici trois cas, dont nous résumerons brièvement le mode opératoire (le lecteur est donc invité à lire les articles cités pour une explication détaillée).
De taxis et d’arcs-en-ciel⁹
La Commission Taxi & Limousine de New York (NYC) donne libre accès, via la loi américaine FOIL, à un jeu de données de 20 Go contenant plus de 173 millions de courses, avec notamment lieu et date de début et fin de la course, ainsi que le numéro de licence du conducteur et l’identifiant du taxi (medallion number) anonymisés. Des geeks s’amusent alors à toutes sortes de manipulations sur ces données et à partager leurs trouvailles sur les forums, notamment Reddit.
On constate que l’anonymisation est probablement déterministe car des mêmes numéros anonymisés reviennent régulièrement. Un jour quelqu’un remarque qu’un numéro de licence apparaît très souvent. L’auteur de l’article cité alors fouille un peu et découvre que ce numéro correspond au hash MD5¹⁰ de 0 (zéro), probablement une erreur de collection des données, une valeur par défaut. Ainsi il découvre que tous les numéros de licence et les medaillon number sont anonymisés simplement par un hashage MD5. Or un hashage est attaquable par force brute lorsqu’on a la moindre information sur la donnée en clair qui rend fini le nombre de possibilités (ce qui est souvent le cas car une telle information peut être simplement : la taille est inférieure à 100 caractères). Bien sûr, plus on a d’informations sur la donnée en entrée, moins les combinaisons à tester sont nombreuses et plus l’attaque en force brute est facile. Bref, dans ce cas il n’y a que quelques millions de combinaisons possibles car les formats des numéros de licence et medallion sont connus : calculer le hash de toutes ces combinaisons avec un ordinateur standard prend quelques heures à peine, ce qui permet à l’auteur de construire une sorte de rainbow table¹¹ (table d’inversion de la fonction de hash), et ainsi réidentifier tous les conducteurs et toutes les voitures du jeu de données.
Résumons les caractéristiques de cette attaque :
- Pas de ciblage de personnes : l’attaquant ne partait pas du principe qu’une cible précise figurait dans le jeu de données
- Aucune donnée tierce nécessaire : l’attaquant n’a pas croisé le jeu avec un autre jeu disponible par ailleurs
- Corrélation : l’anonymisation étant déterministe, il était possible de relier entre eux des enregistrements correspondant à la même personne
- Individualisation par rétro-ingénierie et attaque en force brute sur une fonction d’anonymisation déterministe et facilement inversible
Votre historique de navigation privée n’est pas vraiment privé¹²
Une journaliste allemande se fait passer pour un start-uppeur israélien et demande à une société de data brokerage un jeu d’essai, vendu comme anonyme, afin de valider son modèle et éventuellement lui acheter des données. Sans plus de vérifications, la société accepte et lui envoie l’historique complet de navigation de 3 millions d’utilisateurs allemands pendant un mois, mis à jour en direct en fonction de l’activité de ces mêmes utilisateurs. Les 3 millions d’historiques ne comprennent qu’une liste d’URLs avec le timestamp de visite.
La journaliste, aidée d’un data scientist, collecte les 10 dernières URLs partagées par des politiciens allemands sur Twitter et essaye de retrouver une correspondance dans les historiques de navigation avec les mêmes URLs et les timestamp correspondant approximativement aux horaires de partage Twitter. Bingo : 10 adresses avec timestamp suffisent à isoler un individu parmi les 3 millions fournis dans le jeu de données.
Résumons là encore les caractéristiques de l’attaque :
- Ciblage de certaines personnes spécifiques
- Appel à des données tierces publiques (fil Twitter de personnes ciblées)
- Corrélation entre les URLs des fils Twitter et les historiques de navigation
Comment casser l’anonymité du jeu de données du Prix Netflix¹³
Netflix organise un concours ouvert proposant de prédire les notes que les utilisateurs ont attribuées à certains films à partir simplement de leurs précédentes notations sur d’autres films. Le jeu de données met à disposition pour chaque utilisateur, non identifié, les notes qu’il a attribuées à une série d’autres films et la date d’attribution.
Deux chercheurs ont mis au point une mesure de similarité quantifiant la proximité entre deux jeux de notations. En comparant ainsi les notations de certains utilisateurs choisis (et ayant noté publiquement) sur IMDb avec celles du jeu Netflix, les chercheurs sont parvenus à réidentifier certains utilisateurs du jeu anonymisé Netflix. Notons qu’une systématisation était difficile car elle aurait impliqué un web-scraping du site IMDb, par ailleurs interdit.
Voici les caractéristiques de l’attaque :
- Appel à des données tierces publiques (notations IMDb des utilisateurs)
- Corrélation entre les notations IMDb et Netflix
Au passage, de telles fonctions de similarité sont précisément à la base de nombreux moteurs de recommandations chers aux métiers de ciblage publicitaire ou de fournisseurs de contenu.
Anonymisation : arrêtez tout ? Non, mais réfléchissez !
L’on peut trouver encore de nombreux cas¹⁴ de réidentifications, et ces problématiques ne sont pas récentes du tout, les techniques d’anonymisation disponibles ayant été inventées il y a un certain temps. Il n’y a pas de leçons générales à tirer de ces attaques, la conception d’une bonne anonymisation se fait beaucoup au cas par cas ; l’on peut constater peut-être que les attaques passent souvent par une corrélation avec des données publiques insoupçonnées.
En effet, les attaquants regorgent de créativité et il est difficile mais indispensable de se mettre dans leur peau et d’imaginer les moyens, souvent artisanaux, par lesquels ils peuvent désanonymiser un jeu de données. L’anonymisation, c’est comme la sécurité informatique ou l’évasion fiscale : c’est les gendarmes et les voleurs. Et les voleurs ont toujours une longueur d’avance.
Pour tester votre anonymisation, le mieux reste de jouer à l’attaquant et essayer par tous les moyens de la casser !
Alors si on n’anonymise pas, que fait-on ? Pour les analyses statistiques et marketing, il est toujours possible d’anonymiser par généralisation, ce qui fait perdre de l’information en nous faisant travailler sur des groupes d’individus et non plus sur des individus uniques : elle reste faillible mais moins que les anonymisations injectives, au sens mathématique du terme. Pour ce qui est des tests logiciels, une alternative serait la génération de jeux from scratch, même si elle est complexe et coûteuse. On vient de voir qu’une bonne anonymisation est tout aussi complexe et coûteuse (il suffit de voir le prix des solutions du marché, allant rapidement sur les 100 k€ annuels pour un applicatif sous-jacent standard) ; au moins la génération from scratch engendre un risque moindre.
En somme, il ne faut pas abandonner l’idée d’anonymiser ses jeux de données, mais simplement avoir en tête qu’une bonne anonymisation, ce n’est pas aussi facile qu’on pourrait le croire. Pour espérer son succès, il faut au minimum :
- l’adapter spécifiquement à chaque cas d’usage,
- l’éprouver systématiquement en se plaçant dans la peau de l’attaquant et en imaginant les scénarios d’attaque pour exploiter les failles,
et ceci est valable que l’on se fasse aider par un outil du marché ou pas !
[1] Dans les années 90, la directive Directive 95/46/CE sur la protection des données personnelles évoque la notion de « données anonymes ». De nombreux cas, dont certains sont cités dans cet article, de problèmes liés à l’anonymisation de données sont recensés déjà dans les années 2000.
[2] Les recherches des termes « data anonymisation » sur Google Search, disponibles sur Google Trends entre 2010 et 2018, suivent une tendance à la hausse à partir de l’adoption du RGPD en 2016 pour atteindre un net pic au 1er semestre 2018, juste avant l’entrée en application du règlement.
[3] Voir notre précédent article : Foresto, G. (18/06/2018). « 3 Idées reçues sur les obligations du RGPD — 2/3 Le RGPD impose d’anonymiser les données ». Disponible à l’adresse : https://www.riskinsight-wavestone.com/2018/06/3-idees-recues-sur-les-obligations-du-rgpd-23/, consultée le 12/09/2018
[4] Foresto, G. (26/07/2018) « L’anonymisation de données, une quête encore difficile au lendemain de l’entrée en vigueur du RGPD ». Disponible à l’adresse : https://medium.com/meetech/lanonymisation-de-donn%C3%A9es-une-qu%C3%AAte-encore-difficile-au-lendemain-de-l-entr%C3%A9e-en-vigueur-du-rgpd-6d25522fd2d6, consultée le 12/09/2018
[5] RGPD, Considérant 26
[6] Groupe de travail « Article 29 » sur la protection des données (10/04/2014). « Avis 05/2014 sur les Techniques d’anonymisation ». Disponible à l’adresse : https://www.cnil.fr/sites/default/files/atoms/files/wp216_fr_0.pdf, consultée le 30/08/2018
[7] Foresto, G. (18/06/2018). « 3 Idées reçues sur les obligations du RGPD — 2/3 Le RGPD impose d’anonymiser les données ». Disponible à l’adresse : https://www.riskinsight-wavestone.com/2018/06/3-idees-recues-sur-les-obligations-du-rgpd-23/, consultée le 12/09/2018
[8] Exemple : « Le processus de suppression et d’anonymisation décrit par la société fait apparaître que certaines données demeureraient indirectement identifiantes, ce qui démontre que les données ne feraient pas l’objet d’une purge. », in CNIL. « Décision n° 2015–059 du 24 juin 2015 mettant en demeure la société X ».
[9] Pandurangan, V. (22/06/2014). « On Taxis and Rainbows ». Disponible à l’adresse : https://tech.vijayp.ca/of-taxis-and-rainbows-f6bc289679a1 [EN], consultée le 12/09/2018
[10] Article Wikipédia. « MD5 ». Disponible à l’adresse : https://fr.wikipedia.org/wiki/MD5, consultée le 12/09/2018
[11] Mentionnons également qu’il existe déjà sur internet de nombreuses rainbow tables partielles qui ne demandent qu’à être enrichies, et que dans ce cas on n’a même pas besoin de connaître le format en entrée (pour peu que la table connaisse déjà cette entrée-là). Exemple : https://crackstation.net/, consultée le 12/09/2018
[12] Oberhaus, D. (11/08/2017). « Votre historique de navigation privée n’est pas vraiment privé ». Disponible à l’adresse : https://motherboard.vice.com/fr/article/wjj8e5/votre-historique-de-navigation-privee-nest-pas-vraiment-prive, consultée le 08/01/2018
[13] Narayanan, A.; Shmatikov, V. (22 November 2007). « How To Break Anonymity of the Netflix Prize Dataset ». Disponible à l’adresse : https://arxiv.org/abs/cs/0610105 [EN], consultée le 26/07/2018
[14] Schneier, B. (12/12/2007). « Why ‘anonymous’ data sometimes isn’t ». Disponible à l’adresse : https://www.wired.com/2007/12/why-anonymous-data-sometimes-isnt/ [EN], consultée le 12/09/2018
