Protégez les données personnelles

Considérons un token sécurisé réalisé par l’équipe de recherche Inria PETRUS.

Ce token de la taille d’une grosse clé USB est composé :

• d'un microcontrôleur sécurisé qui va effectuer des calculs et qui sera robuste aux attaques (y compris les attaques physiques assez complexes) ;

• d'une carte SIM (comme celle qu'il y a dans votre téléphone) qui va embarquer des secrets, c’est-à-dire des clés de chiffrement ;

• s'une carte micro SD sur laquelle nous allons pouvoir stocker les données (les données chiffrées, bien entendu, puisque cette carte micro SD peut être sortie et lue par ailleurs) ;

• d'un lecteur d’empreintes permettant d’apporter une double authentification biométrique ;

• d'un dispositif de communication avec l’extérieur, c'est-à-dire le Bluetooth et la prise USB.

Pourquoi utiliser un token ?

Tout d’abord, le token sécurisé est autoadministré ou, plus précisément, le SGBD embarqué sur le token. Il n'y a donc pas d’administrateur, c’est-à-dire que l’utilisateur lui-même stocke ses données et personne d’autre ne peut y avoir accès.

Ensuite, le dispositif est difficile à attaquer. Il a un bon rapport coût de l’attaque sur bénéfice.

En sécurité informatique, on mesure toujours l’impact d’une attaque, parce que mener une attaque est coûteux. Ici, attaquer un tel dispositif est assez coûteux du fait de la sécurisation physique du microcontrôleur. De plus, l'unique bénéfice que nous pouvons obtenir après l’attaque est la récupération de données d’un seul individu.

Un autre avantage est que le token sécurisé est un dispositif portable. Celui-ci peut donc se connecter à n’importe quel dispositif utilisateur qui dispose d’une prise USB (un ordinateur fixe, un ordinateur portable, un téléphone portable, etc.).

Notez aussi que ce dispositif permet de stocker des données et de les récupérer de manière assez transparente.

Enfin, le token va gérer l’authentification, le contrôle d’accès et le contrôle d’usage, à savoir ce qui est fait des données lorsqu’elles sont exportées du système.

Du fait de sa sécurité, le token est peu puissant. De plus, il est peu connecté puisqu’il n’est pas alimenté. En effet, le token est alimenté uniquement lorsqu’il est branché à un ordinateur ou sur une prise USB connectée à une prise de courant.

Le manque de puissance et de connexion entraîne une difficulté algorithmique : sur le token, les algorithmes sont plus complexes à mettre en œuvre.

Enfin, il faut prévoir la durabilité du système grâce à des sauvegardes. Ainsi, en cas de casse du token, les données ne seront pas perdues.

L'architecture asymétrique

Cette architecture tire son nom du fait qu’elle est composée d’un grand nombre de tokens sécurisés peu puissants et faiblement connectés (à gauche du schéma). Ces tokens disposent donc d'une faible puissance et d'une faible disponibilité. En revanche, nous pouvons avoir confiance en ces dispositifs.

Du fait de leur grande déconnectivité, ces dispositifs ne peuvent pas fonctionner seuls. C'est pourquoi une infrastructure de type cloud leur est adjointe (à droite du schéma). Cette infrastructure dispose d'une très grande puissance de calcul et d'une très grande disponibilité (7 jours sur 7, 24 heures sur 24).

Ce cloud est peut-être géré par un opérateur tiers, donc il est possible que des administrateurs puissent regarder tout ce qu’il s'y passe. C'est la raison pour laquelle nous avons une faible confiance en ce cloud.

Nous voyons que cet environnement est plus compliqué à approcher qu’un environnement classique simplement constitué d’un serveur. En voici les raisons.

En effet, tout d'abord, il va falloir mettre en place des algorithmes distribués qui devront fonctionner à la fois sur l’ensemble du token et en collaboration avec le cloud, du fait que les tokens eux-mêmes soient peu puissants.

Ensuite, les tokens sont souvent déconnectés. Effectivement, il n'est pas garanti qu'ils soient connectés, car ils ne disposent pas toujours de la 4G.

Puis, il y a le fait que nous n'avons pas confiance en l’infrastructure de support. Ainsi, si deux éléments de confiance du token cherchent à communiquer entre eux et s'ils ne sont pas connectés, ils vont devoir passer par un tiers qui, lui, ne sera pas forcément de confiance.

Les modèles d’attaque

Les modèles d’attaque concernent deux éléments : l’infrastructure de serveur de support (ISS) et le token.

Concernant l’infrastructure, nous considérons qu’elle est honnête mais curieuse, c’est-à-dire qu’elle joue son rôle. Ici, il est question d'une personne payée pour réaliser les tâches correctement. Cependant, elle peut aussi regarder ce qu’il se passe sur l'infrastructure en observant les données qui y transitent.

Nous pouvons également parler d'infrastructure malicieuse pour désigner une infrastructure qui n’effectue pas correctement les algorithmes. Cela peut être, par exemple, une infrastructure qui cherche à ne pas effectuer tous les calculs parce que cela lui coûte moins cher d’oublier certains traitements. Il peut aussi s'agir d'une infrastructure qui cherche à casser des opérations réalisées par les tokens.

En ce qui concerne le token, nous considérons d'une part qu’il est honnête et incassable. D'autre part, nous pouvons prendre en compte le fait que certains tokens soient cassés, ce qui peut éventuellement engendrer un comportement malhonnête. Dans ce cas, si le token est compromis, les données qui y sont stockées seront perdues. Nous devrons alors regarder si la compromission du token a un impact sur l’ensemble des autres tokens. Si oui, il faut limiter cela, c’est-à-dire que même si un token est cassé, il ne faut pas que l’intégralité du système soit compromise.

Regardons maintenant comment il est possible de réaliser des algorithmes sur une architecture asymétrique.

Un exemple de calcul d'agrégats

Considérons l’exemple d’un calcul de requête SQL avec agrégats, cliquez ici pour visualiser cet exemple.

Nous avons :

• une requête SQL classique (SELECT, FROM, WHERE) ;

• une information de regroupement constituée d’un ensemble d’attributs de regroupement ;

• une clause HAVING qui filtre les groupes ;

• une clause SIZE qui indique la condition d’arrêt (par exemple, un nombre de participants maximum ou une durée de collecte).

Tout d'abord, cette requête est envoyée à l’ensemble des tokens. Chaque token décide s’il veut participer ou non à cette requête. Si l’individu n’habite pas à Bourges, il n’y a aucune raison qu’il envoie ses informations.

Au cours de cette phase de collecte, les informations sont envoyées chiffrées à l’infrastructure de serveur de support avec un chiffrement déterministe.

Pour ce qui est de l’attribut de regroupement (l’âge), il est chiffré de manière diapaniste : deux tokens ayant le même âge auront la même valeur chiffrée qui sera envoyée. Cela va permettre à l’infrastructure de serveur de support de rassembler toutes les informations provenant du même groupe d’âge.

Ensuite, la phase d’agrégation est exécutée. Elle s’effectue sur les tokens. Ainsi, nous allons envoyer des groupes (des ensembles chiffrés d’âge et de salaire) sur le token qui va déchiffrer l’ensemble des salaires, calculer la moyenne et, éventuellement, retourner cette information chiffrée à l’infrastructure de serveur de support.

Une fois que nous avons récupéré pour chaque tranche d’âge la valeur moyenne du salaire, il suffira d’envoyer le tout au token qui a posé la requête. Il pourra ainsi déchiffrer et obtenir le résultat.

Un exemple d'attaque par fréquence

Ici, nous avons fait l’hypothèse selon laquelle la clé de chiffrement est partagée par les tokens et n’est pas connue de l’infrastructure de serveur de support, c’est-à-dire que celle-ci n’est capable de déchiffrer ni l’âge ni le salaire.

La première table contient des comptes bancaires d'utilisateurs et les montants qui sont sur ces comptes en banque.

Imaginons que l’attaquant soit au courant de la structure de cette table. Par exemple, il sait que l’individu Alice possède 2 comptes tandis que Bob, Chris, Donna et Elvis n’en possèdent qu’un seul.

L'attaquant sait également que sur l'ensemble des comptes en banque, 3 disposent de 200 € tandis qu’un seul compte dispose du montant 300 €, 400 € et 500 €. Lorsque l'attaquant regarde la deuxième table qui est chiffrée de manière déterministe, il voit que sur la colonne IC (une colonne à priori chiffrée), la même information se retrouve 2 fois, à savoir la valeur alpha.

Ainsi, l'attaquant peut comparer les numéros des comptes aux distributions qu’il connaît. Les numéros des comptes sont tous différents. Pour ce qui est des noms des clients, un client apparaît 2 fois et 4 autres clients apparaissent une fois. Concernant les montants sur les comptes bancaires, un montant apparaît 3 fois et les autres montants apparaissent une fois.

Donc là, en regardant juste les colonnes IA, IC et IB, l’attaquant est capable de savoir que la colonne IA, c’est le numéro des comptes, la colonne IC, c’est le nom des clients et la colonne IB, c’est le montant qui est présent sur ces comptes bancaires ; et du coup on est capable de déduire les valeurs sur certaines lignes, on est capable de savoir, par exemple, puisqu'à un moment donné la valeur alpha et la valeur kappa sont sur la même ligne, qu'Alice a un compte sur lequel elle a 200 euros.

Dans cette partie, nous sommes rentrés dans un peu plus de détails techniques sur les moyens de sécuriser les données, en particulier le chiffrement des données, le contrôle d'accès, l'utilisation de techniques de fouille de données respectueuses de la vie privée, et l'utilisation de matériel sécurisé. Chacune de ces techniques répond à une protection par rapport à un adversaire bien identifié, qui peut aller de l'administrateur du système à un utilisateur extérieur quelconque.

Dans la partie suivante, nous allons nous concentrer sur les techniques d'anonymisation des données, qui présentent un autre moyen de sécuriser l'analyse de données.