Hackers vs Neural networks: Game on! Part 3/3

Defend against real-world Adversarial attacks !

Mithuran Gajendran
Meetech - We Love Tech
10 min readAug 28, 2020

--

Transposition au monde réel

Les attaques vues précédemment sont réalisables sous beaucoup de contraintes. Idéalement, il faut avoir accès aux données d’entrée du modèle et tester ces attaques directement sur le modèle. Elles sont rendues imperceptibles par l’ajout de quelques pixels directement sur l’image numérique.

Dans la réalité, ce n’est pas aussi simple puisqu’il faut agir sur des objets réels. Il est difficile d’ajouter quelques pixels sur un chat !

La définition d’une attaque ‘adversarial’ est alors amenée à changer.

Nous pouvons réduire la définition d’une attaque “réelle” à :

L’ajout d’une perturbation dans le monde réel, utilisé comme signal d’entrée d’un modèle, suffisante pour permettre la modification de son signal de sortie.

La notion d’imperceptible disparait ! La seule possibilité pour tromper le modèle est de modifier directement l’environnement capturé par la caméra. Ces modifications, effectuées sur des objets réels et ne relèvent plus du pixel, et sont en général impossibles à cacher à un observateur humain.

L’objectif est réduit à tromper le modèle. Le problème est plus simple à résoudre puisqu’il est visible mais n’en est pas moins dangereux.

Quelques cas d’attaques visuelles

Alors ! Ça ressemble à quoi ces attaques ?

Panneau Stop avec un graffiti et des autocollants apposés dessus. Rien de particulier ? Classifié comme panneau limité à 45 !

Regardez ces panneaux ! À l’aide d’autocollants et de graffitis, des chercheurs ont réussi à tromper l’IA d’une voiture autonome. Elle confond le panneau Stop avec celui de 45km/h et n’arrête pas la voiture !

Si ces autocollants sont visibles par un observateur humain, et donc potentiellement enlevés assez rapidement, il suffit d’une seule voiture autonome pour qu’un accident se produise.

Ces attaques réelles peuvent prendre différentes formes. En plus des autocollants de l’exemple précédent une équipe a également réussit à tromper un classifieur d’objets grâce à un badge spécialement conçu. Il confond alors une banane avec un grille-pain.

Grâce à l’ajout d’un badge spécialement conçu, le classifieur confond la banane avec un grille-pain

Une autre équipe, en imprimant une maquette de tortue en 3D avec une carapace recouverte de motifs particuliers, a forcé un classifieur à confondre la tortue avec une arme à feu.

Une tortue reconnue en tant que fusil ?

Ces attaques ‘adversarial’ ne sont pas restreintes au domaine de la recherche informatique mais sont applicables au monde réel. C’est un véritable frein à l’utilisation des modèles de Deep Learning de manière généralisé.

Cas d’usages industriels

Ces attaques sont réelles, et la généralisation de l’IA dans la course à l’automatisation va décupler leur nombre. Chez Wavestone, la robustesse d’un modèle est aussi importante que sa performance. Voici quelques applications que j’ai pu voir dans le cadre de leur missions (non-confidentielles) :

  • Restaurant d’entreprise (pour les gourmands)
Un plateau repas !

Contexte : Utilisation de la reconnaissance d’image pour détecter et analyser le contenu sur un plateau cantine et facturer automatiquement le montant adéquat.

AA : Une attaque ‘adversarial’ pourrait consister à déposer un badge spécial sur le plateau pour tromper le réseau de neurones utilisé afin de réduire, ou annuler, le montant à payer.

L’attaque n’est pas compliquée à mettre en place puisque l’architecture d’un réseau de reconnaissance d’image est assez classique ! Ensuite, il suffit de générer la donnée en prenant des photos d’un plateau depuis le point de vue de la caméra du mécanisme de reconnaissance. Le hacker/gourmand utilisera ensuite ces image pour entraîner un modèle, créer son exemple ‘adversarial’ et attaquer le véritable mécanisme.

Limites : Le problème rencontré lors de cette attaque est la présence d’un contrôle humain en bout de chaîne pour vérifier le bon fonctionnement de l’algorithme et inspecter le plateau ! Ce type d’attaque fonctionnera seulement sur des caisses automatiques sans vérification humaine.

  • Détection de fraude interne
La fuite d’innovations techniques est un fléau majeur !

Contexte : Un modèle de détection de fraudes a été mis en place afin de prévenir la fuite d’informations confidentielles. Ce modèle utilise les données de navigation web et génère plusieurs métriques (temps passé sur une page, data upload/download etc…) et les compare avec les données historiques

AA : Si un employé parvient à accéder à l’architecture du réseau neuronal et le reproduit chez lui il peut s’exercer à créer des attaques ‘adversarial’.

L’employé va générer une perturbation permettant de tromper la détection de fraude et de masquer cet envoie de 1Go en allant par exemple sur des sites spécifiques, avec une durée précise,… de sorte à créer l’information précise trompant le réseau.

Il va réussir à trouver le combo de manipulations à effectuer afin de pouvoir télécharger des données vers l’extérieur sans se faire repérer : par exemple un fichier de 1Go de data sur Dropbox, qui est normalement détecté par le modèle.

Limites : Il est complexe de récupérer les paramètres d’un modèle en production et même si les données utilisées sont simples à reproduire (logs de navigation et métriques associées), il est difficile d’accéder aux valeurs moyennes des logs des employés au sein d’une entreprise (RGPD). Il faut rappeler que les modèles sont souvent déployés sous forme d’APIs sécurisées par l’utilisation de token d’identification.

  • La voiture autonome du MLDL
Oh ! Une Alpine

Contexte : Une voiture autonome en interne chez Wavestone ! La voiture filme son environnement avant de prédire l’action à entreprendre: tourner à gauche, à droite, s’arréter …

AA : Imaginez des stickers sur la route qui pousse l’IA à prédire droite au lieu de gauche… Un véritable désastre ! Cette attaque n’est pas difficile à mettre en place : les modèles de conduites autonomes sont classiques et pour récupérer la donnée, il suffit d’aller sur la route filmer.

Limites : Nous avons jouer sur le preprocessing afin de ne pas prendre en compte les perturbations. Nous avons aussi implémenté un modèle inexistant sur le marché afin qu’il soit difficilement reproduisible. Finalement, nous l’avons entraîné avec des exemples ‘adversarial’ afin qu’il devienne insensible aux perturbations.

Des défenses pour palier à ce problème

Pour résumer, les conséquences de ces attaques peuvent être tragique ! Comment je fais pour me défendre alors ?

L’existence d’attaques ‘adversarial’ induit l’existence de défenses. De nombreuses défenses ont été proposées ces dernières années par la communauté scientifique mais sont, pour la plupart, réfutées peu de temps après avec de nouvelles attaques les rendant obsolètes.

À l’heure actuelle, il existe trois catégories de défenses faisant office d’état de l’art : l’Adversarial Training, la Randomisation et LipReg.

Adversarial Training : la meilleure défense c’est l’attaque

Le concept est simple, il suffit d’ajouter des exemples ‘adversarial’ durant l’entraînement de notre modèle !

La différence lors d’un ‘adversarial’ training est l’insertion d’une phase d’attaque dans la boucle d’apprentissage. Pour chaque image est générée son exemple ‘adversarial’ associé grâce à une technique d’attaque ‘adversarial’ choisie.

Le modèle est entrainé sur l’image original et également sur l’exemple ‘adversarial’. Le modèle apprend à classifier les exemples adversariaux correctement et s’immunise contre ce type d’attaque.

Cette méthode est la plus efficace et la plus prometteuse à l’heure actuelle mais elle n’est pas exempte de défaut.

  • Elle est très gourmande en ressource, il y a besoin de créer l’exemple et ensuite entraîner le modèle dessus.
  • Un exemple ‘adversarial’ est une copie de l’image avec une perturbation, le modèle risque de sur-apprendre sur cette image et être incapable de généraliser sur des images inconnues, c’est l’overfitting. Un modèle qui « overfit » est trop spécialisé sur les éléments du jeu d’entrainement, il sera donc incapable de classer des éléments jamais vu avec précision.

Randomisation : la défense par ajout de bruit aléatoire

Cette seconde méthode est basée sur le principe de masquage de gradient. Pour faire simple, le gradient est un outil mathématique qui est utilisé pour connaître les variations d’une fonction. Il est utilisé ici pour savoir comment faire varier les paramètres du modèle afin de le faire apprendre lors de la phase d’entrainement. En ayant accès à ce gradient, et donc aux paramètres du modèle, un attaquant possède les informations nécessaires pour réaliser une attaque « White-box ». En masquant le gradient, la récupération des informations est empêchée et cela rend l’attaque plus difficile.

Bruit injecté dans la seconde couche

La randomisation permet de masquer le gradient grâce à l’insertion d’un bruit aléatoire dans l’input du modèle. Cela permet de fausser les valeurs du gradient et donc de récupérer des paramètres erronées, inutilisables pour une attaque. Cette technique est efficace contre les attaques utilisant le gradient pour générer leurs exemples adversariaux. En revanche elle est très peu robuste aux attaques de types Expectation Over Transformation (EOT).

Ces attaques consistent à réaliser plusieurs passages dans le modèle en utilisant le même input et récupérer à chaque passage la valeur du gradient. Alors qu’il est constant dans un modèle normal (en utilisant le même input), il varie ici d’un passage à l’autre en raison de l’ajout du bruit aléatoire. En réalisant plusieurs passages il est possible de faire une moyenne et d’approximer le bruit aléatoire généré (basé sur une technique de Monte-Carlo pour les intéressés). Une fois ce bruit approximé, il est possible de faire de même avec le gradient, et en déduire les paramètres du modèle.

Le second désavantage de la randomisation est l’existence d’un compromis entre la robustesse du modèle et sa précision. L’injection d’un bruit aléatoire important dans un modèle lui procure une grande robustesse au détriment de sa précision. A l’inverse un bruit faible n’impactera pas les performances du modèle mais sa robustesse sera diminuée.

LipReg : la régularisation sous contrainte de la constante de Lipschitz

Le nom est barbare mais l’explication derrière cette méthode de défense est assez simple à comprendre. Une attaque ‘adversarial’ consiste en l’ajout d’une petite perturbation de l’input engendrant une grande variation de la fonction de coût, et donc la modification de la sortie du modèle. Dans le cas d’un classifieur cela correspond à une modification de la prédiction de la classe de l’objet.

La perturbation nécessaire à une erreur de classification est très petite

Cette technique est basée sur un postulat simple : s’il est possible de minimiser la variation de la fonction de coût en réaction à une variation de l’entrée, alors il sera bien plus difficile de réaliser des attaques ‘adversarial’. En particulier, il sera compliqué de réaliser des attaques imperceptibles puisque la perturbation sera importante.

De manière très simplifiée, c’est la constante de Lipschitz qui régit cette variation au sein d’un modèle de Deep Learning. En contraignant cette constante à ne pas dépasser un seuil petit, nous limitons la variation de la fonction de coût lors de l’ajout d’une perturbation en entrée.

Grâce à des modifications particulières des fonctions mathématiques au sein du modèle, il est théoriquement possible de garder cette constante de Lipschitz petite et donc « d’aplatir » la fonction de coût. Il sera alors nécessaire d’appliquer une perturbation beaucoup plus grande à l’entrée afin de modifier suffisamment la fonction de coût pour engendrer une erreur dans la sortie. Dans le cas d’un classifieur cela peut se représenter visuellement par une augmentation de l’espace entre les différentes classes.

La perturbation doit être bien plus importante afin de modifier la sortie du classifieur

Pour en savoir plus sur LipReg, rendez-vous ici !
Pour une explication plus simple, jetez un oeil ici !

Mot de la fin !

La recherche continue ! Le Deep Learning se généralise et permet de multiples innovations. Les enjeux de sécurité sont trop importants pour être négligés.

Chaque attaque a une défense !

Une défense efficace pour contrer les exemples ‘adversarial’ générés par une attaque suivant une norme ne protègera pas le modèle contre les exemples générés suivant une autre norme , et inversement. De même, une défense protégeant le modèle contre les attaques utilisant le gradient ne le protège pas contre celles qui n’en ont pas besoin.

Ces défenses spécialisées posent problème puisqu’il est pour l’heure impossible de protéger un modèle simultanément contre la totalité des attaques ‘adversarial’. De nombreuses recherches sont menées pour tenter de résoudre ce problème et des solutions prometteuses sont proposées. C’est notamment le cas des techniques assemblant plusieurs types de défenses. Le Randomized Adversarial Training par exemple consiste à réaliser un Adversarial Training en incorporant également du bruit aléatoire au moment de l’entrainement. Cela permet de bénéficier des avantages de l’Adversarial Training et de la Randomisation.

Négliger la robustesse du modèle, c’est accepter des conséquences qui peuvent être tragique

La marge de progression reste importante et il est crucial que les recherches se poursuivent. Il est dangereux d’utiliser des modèles de Deep Learning sensibles aux attaques dans des projets aux enjeux importants !

Pire, cette problématique étant encore trop peu connue, avec l’essor du Deep Learning, de nombreux modèles sans aucune stratégie de défense sont déjà utilisés dans des domaines où une attaque pourrait avoir des conséquences désastreuses.

Terminé !

Trivial ?

Cet article est écrit en collaboration avec Mickael Gadoud sur la base des travaux d’Alexandre Araujo, doctorant chez Wavestone. Mon but est de simplifier l’aspect technique pour partager les concepts et les enjeux des attaques ‘adversarial’.

Si les concepts vous sont triviaux, allez jeter un oeil sur les travaux d’Alexandre sur son site. Ils sont géniaux, voici mes favoris :

🌱 Merci !

Merci d’avoir suivi cette série d’article ! J’espère que vous aurez découvert les problématiques de robustesse de modèles.

  • Commentez ! Clappez ! Donnez-moi vos retours :)
  • Contactez moi sur mon Linkedin ou mon Github !

Bonne journée 🔥

--

--

Mithuran Gajendran
Meetech - We Love Tech

Data Scientist with financial engineering background | Enjoy cookies & milk | Currently working on a self driving car | Wanting to make an impact