Protégez les données personnelles

L’anonymat dans les dictionnaires

Selon le Larousse, l’anonymat se dit de quelqu’un dont on ignore le nom. D’après le Littré, le mot anonymat désigne ce qui est sans nom. Jusqu’ici, c’est assez simple : si vous n’êtes pas en mesure de connaître le nom d’une personne, cette personne est anonyme.

L’anonymat dans le règlement

Dans le monde numérique, la définition d’anonymat est donnée par le récent règlement européen.

Le règlement va plutôt s’intéresser à la question de ce qu’on peut traiter et de ce qu’on ne peut pas traiter, et quelles données vont être réglementées. Les données qui ne sont pas prises en compte par le règlement européen sont des informations qui ne concernent pas une personne physique identifiée ou identifiable, ou bien des données à caractère personnel qui auraient été rendues anonymes, de telle manière que la personne concernée ne soit pas ou plus identifiable.

Pour nous, le problème consiste donc à identifier si nous sommes ou non capables d’identifier une personne du monde réel et d’associer des données sensibles à cette personne. Si oui, la donnée n’est pas anonyme. Si on n’est pas en mesure de le faire, la donnée est anonyme.

Pourquoi on se pose toutes ces questions ?

Quand vous allez récupérer des données, vous allez vouloir ou devoir les traiter. Ces traitements sont légaux sur des données anonymes. Le règlement l’explicite en disant qu’il ne s’applique pas au traitement d’informations anonymes, y compris à des fins statistiques ou de recherche.

Si nous sommes capables d’extraire des données et des informations des objets connectés et ensuite de les anonymiser, alors nous pourrons faire tous les traitements que nous souhaitons.

Bien sûr, ce règlement et la protection qu’il offre ne sont pas sans raison : il est possible de déduire des informations extrêmement personnelles à partir de données qui, à priori, ne paraissent pas sensibles ou bien qui sont mal anonymisées.

Notre société produit énormément de données. Tous nos objets connectés produisent des données. Nos GPS produisent des données. Nos téléphones en produisent énormément. L’analyse de ces données est utile, soit directement à la personne qui produit ces données pour lui fournir un service plus personnalisé, soit à la société dans le cas, par exemple, d’une étude statistique sur des données médicales pour améliorer les connaissances sur une pathologie.

L’amélioration de la vie quotidienne est l’une des raisons pour laquelle l’offensive de l’Open Data est constatée en France. L’administration française est encouragée à publier un grand nombre de données de manière exploitable. Prenons un exemple : imaginez qu’une agglomération dispose des capteurs nécessaires pour identifier les places de parking libres en temps réel. Si elle rend ces données publiques, elle permet aux concepteurs de réaliser une application qui va guider les automobilistes à trouver plus facilement une place. Sinon, les informations risquent de n’être visibles que sous la forme d’un affichage du nombre de places disponibles à l’entrée du parking ; un peu dommage, non ?

Les applications à partir desquelles il est possible de piloter un objet connecté sont très consommatrices de données. Par exemple, un constructeur d’objets connectés peut vouloir accéder à des données électriques pour construire un thermostat connecté qui permet d’optimiser la consommation électrique d’un foyer. Néanmoins, les données de consommation électriques sont sensibles : si vous disposez de la liste de consommation de son écran électrique, vous pouvez savoir quelle chaîne une personne est en train de regarder. Voici pourquoi certains sets de données sont protégés : même si vous êtes de bonne foi, d’autres personnes pourront se montrer moins scrupuleuses.

Prenons un exemple du site Vincentgarreau. Ce site exploite librement des données de revenus nets annuels moyens par foyer fiscal dans la ville de Paris.

Ces données sont agrégées par station de métro. On peut donc calculer la moyenne du revenu fiscal sur une ligne de métro ou bien par station de métro. Ce sont des données agrégées et statistiques, construites par des données individuelles, contenant les informations sur le revenu. Étant donné que ces données sont agrégées, on présume qu’elles ne vont pas dévoiler d’informations au sujet d’une personne en particulier.

Les individus qui habitent à proximité de la station "Rue du Bac" sur la ligne 12 ont un revenu net moyen par foyer fiscal de 82 000 € environ. Le revenu net est pondéré par le nombre de personnes qui sont dans le foyer. Il existe un calcul permettant de déduire cette information.

Prenons maintenant 2 sujets, Alice et Bob.

Alice habite à côté de la station "Rue du Bac". Bob, un de ses amis d’enfance, l’ajoute comme amie sur Facebook, remarque qu’elle est célibataire d’après son statut, puis trouve son adresse quand Alice partage un événement pour inviter ses amis à son anniversaire. Bob s’intéresse beaucoup aux sites utilisant l’Open Data, et il est curieux de connaître le salaire d’Alice. En consultant simplement le site Vincentgarreau, Bob peut déduire que le salaire d’Alice est probablement assez important. Bob se dit alors que cela vaut le coup d’inviter Alice à boire un verre car elle semble être un parti plutôt intéressant...

Bien sûr, dans cet exemple, Bob connaîtrait vraisemblablement le même type d’information sans ces données statistiques. La seule connaissance que Bob déduit de ces données est un ordre de grandeur issu d’une moyenne, d’une donnée qui est agrégée. Donc, si cette donnée est suffisamment protégée, il n’y aura pas véritablement de problème : il est possible qu'Alice gagne beaucoup plus, ou au contraire beaucoup moins, que cette moyenne.

Laissons Alice mettre Bob sur liste noire.

Contexte

Considérons une base de données comme la figure ci-dessus, composée d’individus. Elle contient des attributs comme le sexe, l’âge et la mutuelle des individus, qui ne sont à priori pas des données très sensibles. Nous avons aussi une colonne de données sensibles qui correspond à des analyses médicales qui ont été faites sur le taux de cholestérol de ces individus.

Une base de données statistiques va autoriser un utilisateur à poser un certain type de requêtes statistiques qui permettra, par exemple, de calculer la moyenne du taux de cholestérol pour tous les individus de sexe masculin :

SELECT AVG(Cholesterol)
FROM Analyses
WHERE Sexe = ‘M’

En revanche, on souhaite interdire des requêtes permettant de chercher le taux précis de cholestérol pour une personne dont on connaît le nom, par exemple Géraldine :

SELECT Cholesterol
FROM Analyses
WHERE Nom = ‘Géraldine’

Bases de données statistiques

Il s’agit donc d’une base de données statistiques qui n’autorise qu’à avoir des informations sur des agrégats. Comment pouvons-nous y arriver ? La première idée serait d’autoriser seulement des requêtes d’agrégats.

SELECT AVG(Cholesterol)
FROM Analyses
WHERE Nom = ‘Géraldine’

À l’intérieur de ce type de requête, on pourra calculer une moyenne, une somme, compter le nombre de personnes, etc. Mais avec cette approche, on pourrait tenter de calculer la moyenne du taux de cholestérol d’un groupe d’une seule personne, non ? Exactement ! Cette approche n’est donc pas du tout sécurisée.

Une protection, une attaque

Il va donc falloir chercher une protection meilleure qu’une simple autorisation des requêtes agrégats. On pourrait par exemple rajouter de manière automatique une clause HAVING, avec une contrainte sur le nombre de n-nuplet qui sont à l’intérieur de cette base de données.

SELECT AVG(Cholesterol)
FROM Analyses
WHERE Nom = ‘Géraldine’
HAVING COUNT(*) > 1

Ici, on dit qu’à l’intérieur d’un groupe, il faut qu’il y ait strictement plus d’une personne. Dans ce cas-là, on va calculer la moyenne du taux de cholestérol pour toutes les personnes qui s’appellent Géraldine. S’il n’y a qu’une seule personne, alors la requête ne retournera pas de résultat.

Malheureusement, cette protection n’est pas suffisante. Regardez : nous allons poser une requête qui va aller nous chercher la moyenne de taux de cholestérol de toutes les personnes qui sont à la MAAF.

SELECT AVG(Cholesterol)
FROM Analyses
WHERE Mutuelle = ‘MAAF’
HAVING COUNT(*) > 1

Dans notre tableau, il y avait 3 personnes concernées : Géraldine, Ivan et Julien. Si on calcule la moyenne de cholestérol pour ces trois personnes, on obtient la valeur 5.

Si on suppose que l’attaquant dispose de connaissances annexes, on peut faire l’hypothèse selon laquelle il sait que Géraldine est à la MAAF, que c’est une femme, et que dans cette base de données, il y a 3 personnes, dont 1 femme et 2 hommes. La moyenne est cette fois-ci à 3,9 :

SELECT AVG(Cholesterol)
FROM Analyses
WHERE Mutuelle = ‘MAAF’
AND SEXE = ‘M’
HAVING COUNT(*) > 1

Il est possible de poser une requête qui va aller récupérer les informations complémentaires à celles de Géraldine, tout en respectant cette contrainte de nombre de personnes dans un groupe. Il suffit en effet de poser une requête qui va aller chercher la moyenne du taux de cholestérol pour les individus de sexe masculin qui cotisent à cette mutuelle, puis d’effectuer le petit calcul basique (3 x 5) – (2 x 3,9) pour obtenir le taux de cholestérol de Géraldine, soit 7,2.

Utilisation des bases de données statistiques

Nécessairement, il faudra que le système limite les requêtes posées, en mémorisant l’information qui a été accédée, et interdise à l’utilisateur d’effectuer des requêtes à un moment. Ce type de système existe, mais nous allons laisser de côté ces bases de données statistiques.