Published by et

Il y a 2 semaines -

Temps de lecture 17 minutes

Attaquer des modèles de machine learning : la confidentialité différentielle – PARTIE 2

Dans l’article précédent, nous avons montré ce que signifie attaquer un modèle, les différents types d’attaques et les concepts nécessaires. L’objectif de cet article est de se concentrer sur la confidentialité différentielle : une technique pour se protéger contre les membership inference attacks, au moins en théorie. Pour rappel, les membership inference attacks sont des attaques ayant pour objectif de découvrir si oui ou non un individu fait partie de la base de données d’entraînement d’un modèle. Nous avons implémenté une attaque, voyons ce que cela donne en pratique.

Retrouver une donnée rare et sensible dans le jeu de données d’entraînement c’est possible ?

Pour mieux comprendre la suite de l’article, nous allons parler d’un cas concret étudié dans cet article : The Secret Sharer: Evaluating and Testing Unintended Memorisation in Neural Networks [1]. Les auteurs ont mené une attaque contre un modèle de génération de séquences accessible en mode black box pour récupérer une information très sensible et très rare présente dans le jeu de données d’entraînement tel qu’un numéro de sécurité sociale. Un modèle génératif de séquences est un type de réseau de neurones qui peut être utilisé pour générer du texte : étant donné le début d’une phrase, le modèle va essayer de suggérer les mots qui suivent. Ces modèles peuvent servir à l’auto-complétion entre autres (dans Gmail, on parle de fonctionnalité de rédaction intelligente). Le modèle apprend sur un corpus de textes dans lequel on peut trouver des informations sensibles qu’il ne faudrait pas retrouver au moment de proposer une suggestion. Ce problème est connu et bien illustré dans la vignette suivante.


Les auteurs de l’article ont donc volontairement inséré dans le jeu de données d’entraînement deux numéros de sécurité sociale. Une fois le modèle entraîné, ils l’ont interrogé et en tapant le début d’une phrase « my social security number is 0 » le modèle leur a proposé exactement le numéro de sécurité sociale présent dans les données d’entraînement. En entraînant de nouveau le modèle avec la confidentialité différentielle, dont on va parler juste après, le problème ne s’est plus présenté.

Dans ce cas, la confidentialité différentielle semble être une solution, mais nous ne pouvons pas en déduire que c’est le cas pour toutes attaques de type membership inference. En effet, l’exemple ci-dessus est un type spécial de membership inference attack, car on a pu non seulement déduire qu’une donnée faisait partie du jeu de données d’entraînement, mais aussi récupérer cette donnée en clair. On parle plutôt de mémorisation non intentionnelle (unintentional memorisation en Anglais).

La confidentialité différentielle

La confidentialité différentielle, connue en anglais sous le nom de differential privacy (DP), est une théorie mathématique [2] qui fournit une forme de protection des données. La manière dont la confidentialité différentielle traite le problème de la protection de données consiste à assurer la confidentialité par le biais d’un processus dont on dira qu’il est différentiellement confidentiel (differentially private), et non en agissant directement sur les données d’entrée.

Dans un contexte de base de données requêtables, la confidentialité différentielle vise à ne pas dévoiler vers l’extérieur l’appartenance à la base même d’une entité qu’elle contient. L’objectif est d’empêcher n’importe qui envoyant des requêtes d’être capable de pouvoir affirmer la présence de données d’un individu précis dans la base. Autrement dit, la confidentialité différentielle aborde le paradoxe de ne rien apprendre sur un individu tout en apprenant des informations utiles sur une population.

La confidentialité différentielle garantit mathématiquement que le résultat d’une analyse sera sensiblement le même si l’on retire les données privées d’un individu particulier de l’ensemble des données d’entrée.

Considérons maintenant le contexte du machine learning et du deep learning en particulier, où l’on cherche à modéliser un problème en entraînant un modèle sur un jeu de données de taille importante et bien représentatif de la problématique modélisée. Le modèle apprend à partir des données et il ne devrait pas exposer d’informations sur le jeu de données d’entraînement. Comme dans le contexte de base de données, avec la confidentialité différentielle, le souhait est de ne pas dévoiler la présence d’un individu dans le jeu de données d’entrée en ayant accès au modèle entraîné.

Pour clarifier l’idée derrière la confidentialité différentielle, on vous propose le schéma simplifié ci-dessous. Si on entraîne un modèle sur une base de données avec n entrées on obtient une sortie O. Si on entraîne le même modèle sur une base de données qui est identique à la précédente sauf pour une entrée, on obtiendra une sortie O’O≠ O’.


Si on répète l’expérience, maintenant en ajoutant la confidentialité différentielle à l’entraînement (on verra par la suite ce que cela veut dire), on s’attend à obtenir O dans les deux cas, quelle que soit l’entrée ayant été retirée de la base d’input.

Ce concept est exprimé en termes de probabilité d’obtenir un même output par la définition formelle de la confidentialité différentielle. Les avantages d’avoir une définition mathématique sont multiples :

  • la confidentialité différentielle a des propriétés telles que la composabilité, la confidentialité des groupes et la robustesse aux informations auxiliaires qui peuvent être facilement exploitées pour une utilisation en machine learning ;
  • il est facile de transformer une fonction déterministe en un algorithme différentiellement confidentiel ;
  • la garantie de confidentialité obtenue est quantifiable.

De la théorie à la pratique

Concrètement, comment obtenir un modèle qui soit différentiellement confidentiel, c’est-à-dire un modèle qui respecte les propriétés de la confidentialité différentielle ? Bien que la théorie mathématique soit assez complexe, l’implémentation algorithmique est relativement simple et accessible.

Dans l’apprentissage automatique, la façon de rendre le processus d’entraînement d’un modèle différentiellement confidentiel est de rendre la descente stochastique du gradient différentiellement confidentielle. Ceci est essentiellement réalisé en ajoutant du bruit Gaussien au gradient à chaque itération d’apprentissage. Une dernière étape est aussi nécessaire : effectuer un clipping lors de la descente de gradient avant d’ajouter du bruit. Ce clipping du gradient est une pratique courante pour éviter le sur-apprentissage même lorsque la confidentialité n’est pas un enjeu. Ici, c’est une étape nécessaire pour respecter les propriétés mathématiques de la confidentialité différentielle.

Ces considérations font l’objet de cet article [3] qui propose le pseudo-code d’une descente de gradient différentiellement confidentielle :

La recherche théorique a mené au développement de TensorFlow Privacy, une librairie de la famille de TensorFlow qui fournit une implémentation de la version différentiellement confidentielle de 4 optimiseurs largement utilisés :

  • sgd → DPGradientDescentGaussianOptimizer
  • adam → DPAdamGaussianOptimizer
  • adagrad → DPAdagradGaussianOptimizer
  • rmsprop → DPRMSPropOptimizer

Pour entraîner un modèle différentiellement confidentiel il suffit d’utiliser l’un de ces optimiseurs importé depuis privacy.optimizers.

Voyons rapidement un morceau de code qui illustre l’implémentation d’un modèle keras à entraîner avec confidentialité différentielle. Admettons que nous ayons un flag train_with_differential_privacy : s’il est égal à True on entraîne avec confidentialité différentielle, autrement on entraîne comme d’habitude avec l’optimiseur de keras. Il y existe une implémentation des optimiseurs différentiellement confidentiels spécifique à keras dans TensorFlow privacy.

Dans les arguments passés à l’optimiseur de TensorFlow Privacy on remarque la valeur de clipping et le noise_multiplier qui contrôle l’écart type du bruit Gaussien introduit. À la suite de la compilation, il y aura l’appel à la méthode fit du modèle comme d’habitude.

from tensorflow_privacy.privacy.optimizers.dp_optimizer_keras import DPKerasSGDOptimizer
 
# Load training and test data.
train, test = tf.keras.datasets.mnist.load_data()
 
# Define a sequential Keras model
model = tf.keras.Sequential([
    ...
])
 
train_with_differential_privacy = True
 
 
if train_with_differential_privacy == True:
    optimizer = DPKerasSGDOptimizer(
        l2_norm_clip=l2_norm_clip,
        noise_multiplier=noise_multiplier,
        num_microbatches=microbatches,
        learning_rate=learning_rate)
    # Compute vector of per-example loss rather than its mean over a minibatch.
    loss = tf.keras.losses.CategoricalCrossentropy(
        from_logits=True, reduction=tf.losses.Reduction.NONE)
else:
    optimizer = tf.keras.optimizers.SGD(learning_rate=learning_rate)
    loss = tf.keras.losses.CategoricalCrossentropy(from_logits=True)
 
# Compile model with Keras
model.compile(optimizer=optimizer, loss=loss, metrics=['accuracy'])

Confidentialité différentielle et performances

Dans la pratique, l’entraînement d’un modèle différentiellement confidentiel se fait assez facilement. Nous conseillons de suivre ce tutoriel officiel pour prendre en main le code très rapidement.

Une fois le modèle entraîné, il est possible d’utiliser le module analysis pour calculer les garanties mathématiques de confidentialité offertes par la théorie de la confidentialité différentielle.

L’objectif de cette analyse ultérieure est de savoir dans quelle mesure un adversaire potentiel pourrait améliorer ses hypothèses sur l’appartenance d’un individu à la base d’entraînement en observant le résultat de la procédure d’entraînement (les paramètres du modèle entraîné). Pour plus de détails sur cette partie, vous pouvez aussi lire Machine Learning with Differential Privacy in TensorFlow [4] écrit par un des auteurs de TensorFlow Privacy.

Cette garantie est parfois appelée budget de confidentialité (privacy budget). Un budget de confidentialité « petit » limite plus étroitement la capacité d’un adversaire à améliorer sa supposition. Cela signifie une plus grande garantie de confidentialité. Intuitivement, cela est dû au fait qu’il est plus difficile pour n’importe quel point d’entraînement d’affecter le résultat de l’apprentissage : par exemple, les informations contenues dans un point spécifique ne peuvent pas être mémorisées par l’algorithme ML et l’anonymat de la personne qui a contribué à l’ensemble de données est conservé.

Selon sa définition, la confidentialité différentielle est exprimée par deux paramètres :

  • correspond au budget de confidentialité. C’est la borne supérieure de la variation de la sortie d’un modèle lorsque l’on exclut un seul point d’entraînement (un seul individu). Une valeur plus petite pour implique une meilleure garantie de confidentialité. Cependant, la valeur n’est qu’une limite supérieure et une valeur élevée pourrait encore signifier une bonne confidentialité dans la pratique.
  • δ représente la probabilité d’échec de la confidentialité ε-différentielle. Plus est faible, plus la probabilité que la confidentialité ne tienne pas (au sens mathématique[4]) est faible. Le choix d’un inférieur à l’inverse de la taille des données d’entraînement est considéré comme suffisamment petit.

Le module analysis implémenté dans TensorFlow Privacy met à disposition une fonction, compute_dp_sgd_privacy.py, pour calculer  étant donné (égal à 1/nombre d’exemples d’entraînement) et les hyperparamètres suivants :

  • La taille de données d’entraînement, n ;
  • La taille de batch, batch_size ;
  • La quantité de bruit échantillonnée et ajoutée aux gradients pendant l’entraînement, noise_multiplier ;
  • Le nombre d’époques, epochs.

Nous avons utilisé l’exemple de classification fourni par les auteurs de TensorFlow Privacy pour vérifier le comportement du modèle avec différentes valeurs du paramètre noise_multiplier. Dans la figure suivante, vous trouvez en abscisse le noise_multiplier et en ordonnée, respectivement, , l’accuracy sur le jeu de données de validation et le temps d’entraînement. On remarque qu’en introduisant plus de bruit le budget de confidentialité () diminue avec en conséquence une meilleure garantie de confidentialité et en même temps une perte de performance (l’accuracy décroît). Le temps d’entraînement n’est pas spécialement impacté. Il faut quand même noter que l’entraînement du même modèle avec les mêmes paramètres et sur la même machine avec un optimiseur classique ne prend que 40 secondes contre plus de 2000 avec confidentialité différentielle.

Maintenant que l’on sait comment quantifier la confidentialité et que l’on a un critère selon lequel choisir un modèle (un compromis entre et accuracy), il reste encore une question. Concrètement, quel niveau de sécurité a-t-on obtenu et contre quoi protège-t-il les données  ?

Retour d’expérience sur les Membership inference attacks

Maintenant que nous avons une idée plus claire sur la confidentialité différentielle, nous allons nous demander si elle permet de répondre à la vulnérabilité face à une membership inference attack et quel niveau de confidentialité (valeur de ) est suffisant pour assurer la protection. Dans le but de répondre à ces questions, nous avons essayé de reproduire une attaque en s’inspirant d’un papier de recherche : Towards Demystifying Membership Inference Attacks [5]. Nous allons détailler le fonctionnement de l’attaque et présenter les résultats.

Voici la procédure de l’attaque dans les grandes lignes. Étant donné un modèle cible entraîné sur un jeu de données D et une donnée d, l’attaque a pour but de déterminer si d appartient à D. Le modèle cible peut être, par exemple, un service de classification mis à disposition en ligne. Dans l’article on suppose que le modèle est accessible en mode black box.

Le modèle ciblé

Nous avons tenté de reproduire une membership inference attack contre un classificateur entraîné sur le jeux de données Cifar10 constitués d’image de taille 32x32x3 regroupées en 10 catégories. Voici quelques exemples d’images avec leur catégorie.

Le modèle ciblé est un réseau de neurones convolutionnel entraîné pour déterminer la catégorie de l’image qu’il reçoit en input.

L’attaque

1/  Trouver un jeu de données « proche » de celui ayant permis d’entraîner le modèle cible et entraîner un modèle shadow sur ce jeu de données.


Pour mener l’attaque il faut d’abord substituer le jeu de données D (qui n’est pas accessible) par un jeu de données appelé D’. Pour créer D’, on peut chercher un jeu de données public similaire à D ou bien réaliser des simulations en se servant d’informations générales sur le type de données, leurs distributions, etc. Ces informations peuvent, par exemple, être tirées des prédictions fournies par le modèle attaqué ou encore provenir de connaissances générales de la population constituant la base d’entraînement. Pour en savoir plus sur les techniques permettant de construire un jeu de données D’, vous pouvez vous référer à la section 3.1 de l’article Towards Demystifying Membership Inference Attacks.

Les données Cifar 10 étant découpées en batchs de 10 000 images, le modèle cible et le modèle shadow sont entraînés sur des batchs différents.

D’ est un jeu de données qu’on peut utiliser pour entraîner un modèle, dit shadow, qui simule le comportement du modèle cible. Le jeu de données D’ est séparé en deux parties : une partie pour l’entraînement D'(in) et une partie pour la validation du modèle shadow D'(out). L’essentiel est que la partie pour la validation, D'(out), ne soit jamais utilisée pour entraîner le modèle.

Lorsque le type de modèle attaqué est connu, on peut utiliser le même modèle pour l’entraînement shadow. Sinon, plusieurs techniques, non développées ici, peuvent être utilisées pour choisir le type de modèle pour cette partie.

2/ Créer les données qui vont servir à entraîner le modèle d’attaque.

Les prédictions de D’ par le modèle shadow servent à construire un jeu de donnée D* qui permettra d’entraîner l’attaque. D* est constitué :

  1. des prédictions du modèle shadow sur D’(out) associé au label « faux » (la partie de donnée qui n’a pas servi à entraîner le modèle shadow) ;
  2. des prédictions du modèle shadow sur D’(in) associé au label « vrai ».

3/ Entraîner l’attaque.

La dernière partie de l’attaque consiste à entraîner un classificateur binaire sur D* qui va apprendre à distinguer entre données utilisées et non utilisées par le modèle shadow.

Les résultats

Le modèle d’attaque est ensuite appliqué contre des images du Cifar10 pour prédire si elles ont été utilisées pour entraîner le modèle cible. Il est à noter que nous ne pouvons analyser les résultats que dans le cadre d’une expérimentation. Une vraie attaque ne pourra déterminer les performances que sur le modèle shadow qui peuvent être éloignées des performances réelles.

Le modèle attaqué a des performances correctes (le problème du Cifar10 est connu pour ne pas être soluble de manière immédiate), il obtient une accuracy de 61% (contre 10% avec une prédiction aléatoire) après 150 epochs. L’attaque quant à elle n’est pas pleinement satisfaisante. Elle est néanmoins meilleure qu’une simple prédiction aléatoire puisqu’elle atteint 64% d’accuracy (en vert dans le tableau) contre 50% pour une prédiction aléatoire.

Nous avons testé la confidentialité différentielle pour voir si cela permet de se protéger contre l’attaque, d’abord avec noise multiplier de 1,5 (résultats en bleu dans le tableau). Dans les mêmes conditions d’entraînement l’attaque devient inefficace contre un modèle entraîné avec confidentialité différentielle. Toutefois, on note une baisse importante des performances du modèle ciblé dont l’accuracy descend jusqu’à 47% (en rouge dans le tableau). En comparaison, un modèle entraîné sur 15 epochs seulement obtient un niveau de performance comparable et rend l’attaque inopérante également. Cette constatation est d’autant plus importante que le temps d’entraînement du modèle est multiplié par environ 100 lorsque l’on utilise la confidentialité différentielle (1s par epoch sans DP et 103s/epoch avec DP).

On peut diminuer la valeur du paramètre noise multiplier (nous  avons testé 1,2 et 1,1) pour gagner un peu en performances sur le modèle initial (target model) tout en gardant une protection contre l’attaque (résultats pas présentés dans ce tableau). Toutefois, le modèle reste quand même moins bon que lorsqu’il est entraîné sans confidentialité différentielle.

Conclusion

La démonstration mathématique des qualités de la confidentialité différentielle donne confiance dans la méthode, notamment pour éviter de mémoriser d’informations sensibles et rares. Mais cela reste relativement théorique et notamment pour les membership inference attacks il faut mener l’attaque de manière pratique pour vérifier l’intérêt de la confidentialité différentielle. Même l’article que nous avons examiné mène à une conclusion pas définitive et évoque la nécessité de développer d’avantage la recherche :

« Further research is necessary to understand which differential privacy mechanisms under what settings are able to provide viable protection to membership inference without forfeiting model utility ». [5]

Il y a un arbitrage à faire notamment sur les concessions en termes de durée d’entraînement, de performances du modèle et la protection grâce à cette méthode. La confidentialité différentielle est intéressante et facile à implémenter dans le code. Cependant, elle n’est pas toujours justifiée, en particulier lorsque l’attaque est peu probable (les conditions pour mener une attaque sont très difficiles à rassembler) et les pertes de performances sont importantes. D’autres contre-mesures peuvent être mises en place. Nous en parlons dans le prochain article.

References

[1] The Secret Sharer: Evaluating and Testing Unintended Memorisation in Neural Networks Nicholas CarliniChang LiuÚlfar ErlingssonJernej KosDawn Song, 2019

[2] The algorithmic foundations of differential privacy

[3] Deep Learning with Differential Privacy, Martín Abadi, Andy Chu, Ian Goodfellow, H. Brendan McMahan, Ilya Mironov, Kunal Talwar, Li Zhang, 2016

[4] Machine Learning with Differential Privacy in TensorFlow, Nicolas Papernot, 2019

[5] Towards Demystifying Membership Inference Attacks, Stacey Truex, Ling Liu, Mehmet Emre Gursoy, Lei Yu, and Wenqi Wei, 2019

Published by et

Publié par Giulia Bianchi

Giulia est Data Scientist, consultante et formatrice à Xebia. Elle travaille actuellement sur des volumes de données importants en mettant en place des algorithmes de Machine Learning, avec un objectif concret d’industrialisation. Elle participe à l’organisation du [DataXDay](https://dataxday.fr/). Elle suit les nouvelles tendances du monde de la Data en participant aux différents Meetups et en suivant des blogs. Elle contribue activement à cet écosystème en donnant des [talks](https://speakerdeck.com/giulbia) et en écrivant sur le [blog Xebia](https://blog.engineering.publicissapient.fr/author/gbianchi/).

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.