A la croisée de plusieurs disciplines, la Data Science s’appuie sur des méthodes et des algorithmes pour tirer des informations et de la connaissances à partir de données structurées et non structurées. Encore inconnus il y a quelques années, les métiers de la Data Science et du Machine Learning évoluent très vite. Compétences, méthodes, outils… dans cette série d’entretiens, nous confrontons notre expérience à celle du marché, avec la participation de Data Scientists et spécialistes de l’IA externes à Devoteam Revolve.

Nous recevons aujourd’hui Marie Paindavoine, co-fondatrice de Skyld, une entité spécialisée dans la sécurité des projets d’IA, avec pour missions de protéger la vie privée des utilisateurs, et de garantir la confiance dans les algorithmes, notamment grâce à la cryptographie.

Comment est venue l’idée de Skyld ?

J’ai un doctorat en cryptographie. J’ai fait ma thèse chez Orange, sur les méthodes de chiffrement avancées et les technologies permettant la protection de la vie privée. En effet, avec le chiffrement “classique”, c’est tout ou rien : les données sont chiffrées ou ne le sont pas, et quand elles sont chiffrées, on ne peut pas les traiter. Par exemple, on ne peut pas faire de recherches sur les données, et encore moins calculer sur les données chiffrées. J’ai donc travaillé sur des techniques de chiffrement (cherchable, homomorphe), qui permettent de traiter des données chiffrées.

J’ai ensuite travaillé chez Renault comme architecte cybersécurité. Durant ces expériences professionnelles, j’ai vu les programmes d’IA se multiplier, sans pour autant y associer une stratégie de cybersécurité dédiée. Cela pose des problèmes de sécurité en général, de confiance en l’IA, ou de protection de la vie privée.

D’où l’idée de Skyld, une entité spécialisée dans la sécurité des projets d’IA, avec pour missions de protéger la vie privée des utilisateurs, et de garantir la confiance dans les algorithmes. A savoir, ne pas pouvoir tromper un algorithme, ni être trompé par un algorithme.

Quelles sont les menaces de sécurité sur la confiance accordée aux algorithmes ?

Les algorithmes prennent un certain nombre de décisions à notre place. Il peut s’agir de conduite autonome, de décision médicale, de détection de ransomware, etc. Or, il est assez simple de créer des images, des sons ou des textes qui ne peuvent être distingués de l’original par l’humain, mais qui ont une signification différente pour l’IA. Ce sont des exemples adversariaux. 

Par exemple, un petit sticker placé sur un panneau Stop peut tromper l’algorithme, qui identifiera le panneau comme une canette de soda, et donc continuera sa route. Ceci montre bien pourquoi la question de la confiance est importante. 

A l’inverse, les algorithmes d’IA sont à l’heure actuelle en mesure de produire des images et des vidéos de personnes, célèbres ou non, qui sont extrêmement difficiles à distinguer de photos ou vidéos réelles. 

On ne doit ni pouvoir tromper les algorithmes, ni être trompé par les algorithmes.

Comment définir la sécurité d’un algorithme ?

Le fait que l’algorithme prenne la décision que je veux au moment où je le veux est une propriété de sécurité. Dans le cas de la voiture autonome, la confiance et la sécurité des utilisateurs sont directement liées. C’est également le cas pour un outil de détection de malwares : si un attaquant peut faire passer un logiciel malveillant pour un fichier bénin, les conséquences sont dévastatrices pour la cible. Les exemples construits ne sont pas aléatoires, ils sont conçus dans un objectif spécifique.

Il faut ainsi également comprendre comment ces algorithmes d’intelligence artificielle prennent leurs décisions, et quels sont les paramètres internes qui peuvent être exploités pour les faire dévier de leur objectif original. La connaissance interne du fonctionnement d’un algorithme est un avantage clé pour l’attaquer. 

Quel périmètre couvrez-vous avec Skyld ?

Notre objectif à long terme est de proposer une expertise de sécurité IA à 360, avec des solutions logicielles couvrant tous les aspects : protection des données, explicabilité des algorithmes, protection du code et de la propriété intellectuelle.

Aujourd’hui, nous nous concentrons sur les algorithmes embarqués, car ils sont déployés dans un environnement entièrement contrôlable par un attaquant, ce qui augmente la possibilité de pouvoir mener des attaques aux conséquences importantes. 

Nous travaillons prioritairement sur l’axe de protection du code et de la propriété intellectuelle. Développer un algorithme d’IA est un investissement de temps et d’argent, dans l’objectif de conquérir des parts de marché. Or, un concurrent peut s’approprier l’algorithme à moindre coût en faisant du reverse engineering. Une attaque de reverse engineering peut également être une première étape vers des attaques plus sophistiquées. Une fois les paramètres et l’architecture du modèle connus, l’attaquant pourra créer extrêmement facilement des exemples adversariaux pour tromper le modèle. Il pourra également mener des attaques par membership inference, c’est-à-dire déterminer si des données faisaient partie des données d’entraînement ou pas, ce qui pose des problèmes de protection de la vie privée, notamment dans les cas d’IA médicale. 

Comment fonctionne votre solution ?

Pour l’instant, nous nous concentrons sur comment protéger un modèle du reverse engineering. Pour que le modèle soit une boîte noire pour l’attaquant, nous utilisons plusieurs techniques qui rendent le code illisible, comme la cryptographie ou l’obfuscation.

Notre plus grande contrainte est de préserver l’accès des algorithmes aux accélérateurs matériels (puces dédiées à l’IA, GPU…). Préserver cet accès tout en protégeant l’algorithme est l’élément différenciateur de notre solution.

A quel moment du développement ML la solution intervient-elle ?

Nous intervenons lorsque le modèle a été entraîné et exporté avec un framework de ML comme Tensorflow. On s’interface alors avec le framework  pour pouvoir proposer une version protégée du modèle, avant qu’il soit envoyé dans un device par exemple. Nous fournissons également le SDK permettant d’exécuter le code protégé au sein du device. 

Est-ce que la solution allonge le temps de réponse de l’algorithme ?

Dès qu’on modifie le code pour le rendre inintelligible, on allonge nécessairement le temps d’exécution, mais le fait de pouvoir continuer à utiliser les accélérateurs matériels diminue le malus. Pour l’instant, un modèle exécuté avec notre solution a un temps d’inférence de 2 à 2,5 fois plus lent. Nous travaillons pour améliorer cela, mais on reste quand même en dessous des 300 millisecondes, une frontière communément admise pour une réponse en temps réel. Les solutions d’obfuscation logicielles classiques sont généralement 30 fois plus lentes, donc on a plutôt bien optimisé notre solution.

Quel langage de programmation utilisez-vous ?

Notre solution est prototypée pour le moment en Python et en C++. Nous sommes en train de travailler à l’interface avec des framework classiques de machine learning comme Pytorch ou Tensorflow pour proposer un SDK qui cache la “laideur” de la protection, et qui soit simple à utiliser par les équipes

Où en êtes-vous aujourd’hui ?

Nous avons un démonstrateur, une preuve de faisabilité de la solution et nous sommes en mesure de proposer des audits aux entreprises intéressées. Nous recherchons activement un partenaire pour déployer une première preuve de concept.

Nous sommes en incubation au sein de l’Inria Start Up Studio, ce qui permet d’accéder aux meilleurs experts français en intelligence artificielle et en cyber sécurité. En plus de l’équipe dirigeante, nous avons deux ingénieurs financés par l’Inria.