Les menaces de cybersécurité pèsent sur les systèmes d’intelligence artificielle des terminaux – EE Times Asia

Avec l’IA des terminaux (ou TinyML) à ses balbutiements et lentement adoptée par l’industrie, de plus en plus d’entreprises intègrent l’IA dans leurs systèmes à des fins de maintenance prédictive dans les usines ou même de repérage de mots clés dans l’électronique grand public. Mais avec l’ajout d’un composant IA dans votre système IoT, de nouvelles mesures de sécurité doivent être envisagées.

L’IoT a mûri à un point tel que vous pouvez lancer des produits de manière fiable sur le terrain en toute tranquillité d’esprit, avec des certifications qui garantissent que votre IP peut être sécurisée grâce à une variété de techniques, telles que des moteurs de sécurité isolés, un stockage de clé cryptographique sécurisé et Arm Utilisation de TrustZone. De telles assurances peuvent être trouvées sur les microcontrôleurs (MCU) conçus avec des fonctionnalités de sécurité matérielles évolutives. L’ajout de l’IA conduit cependant à l’introduction de nouvelles menaces qui infestent les zones sécurisées, notamment sous la forme d’attaques contradictoires.

Les attaques contradictoires ciblent la complexité des modèles d’apprentissage en profondeur et les mathématiques statistiques sous-jacentes pour créer des faiblesses et les exploiter sur le terrain, entraînant la fuite de parties du modèle ou de données de formation, ou produisant des résultats inattendus. Cela est dû à la nature de la boîte noire des réseaux de neurones profonds (DNN), où la prise de décision dans les DNN n’est pas transparente (c’est-à-dire, la présence de couches cachées et les clients ne sont pas disposés à risquer leurs systèmes avec l’ajout d’une fonctionnalité d’IA, ralentissement de la prolifération de l’IA jusqu’au point final).

Les attaques contradictoires sont différentes des cyberattaques conventionnelles, car lorsque des menaces de cybersécurité traditionnelles se produisent, les analystes de la sécurité peuvent corriger le bogue dans le code source et le documenter de manière approfondie. Étant donné qu’il n’y a pas de ligne de code spécifique que vous pouvez adresser dans un DNN, cela devient naturellement difficile.

Des exemples notables d’attaques contradictoires peuvent être trouvés dans de nombreuses applications, comme lorsqu’une équipe de chercheurs, dirigée par Kevin Eykholt, a apposé des autocollants sur des panneaux d’arrêt, ce qui a amené une application d’IA à le prédire comme un panneau de vitesse. Une telle classification erronée peut entraîner des accidents de la circulation et une plus grande méfiance du public à l’égard de l’utilisation de l’IA dans les systèmes.

Les chercheurs ont réussi à obtenir 100 % d’erreurs de classification en laboratoire et 84,8 % lors de tests sur le terrain, ce qui prouve que les autocollants étaient assez efficaces. Les algorithmes trompés étaient basés sur des réseaux de neurones à convolution (CNN), de sorte qu’ils peuvent être étendus à d’autres cas d’utilisation utilisant CNN comme base, tels que la détection d’objets et la détection de mots clés.

Un autre exemple par des chercheurs de l’Université de Californie à Berkley a montré qu’en ajoutant du bruit ou de la perturbation à n’importe quelle musique ou parole, cela serait mal interprété par le modèle d’IA pour signifier autre chose que la musique jouée, ou cela amènerait l’IA à transcrire quelque chose complètement. différent et pourtant la perturbation reste inaudible à l’oreille humaine.

Cela peut être utilisé de manière malveillante dans des assistants intelligents ou des services de transcription IA. Les chercheurs ont reproduit la forme d’onde audio qui est similaire à plus de 99,9 % au fichier audio d’origine, mais peut transcrire n’importe quel fichier audio de leur choix avec un taux de réussite de 100 % sur l’algorithme Mozillas DeepSpeech.

Types d’attaques contradictoires

Pour comprendre les nombreux types d’attaques contradictoires, il faut examiner le pipeline de développement TinyML conventionnel, comme illustré à la figure 3. Dans le pipeline de développement TinyML, la formation est effectuée hors ligne, généralement dans le cloud, suivie de l’exécutable binaire poli final flashé sur le MCU et utilisé via des appels API.

Le flux de travail nécessite un ingénieur en apprentissage automatique et un ingénieur embarqué. Étant donné que ces ingénieurs ont tendance à travailler dans des équipes distinctes, le nouveau paysage de la sécurité peut entraîner une confusion sur la répartition des responsabilités entre les différentes parties prenantes.

Les attaques contradictoires peuvent se produire dans les phases d’entraînement ou d’inférence. Au cours de la formation, un attaquant malveillant pourrait tenter d’empoisonner le modèle, qui peut être de type ciblé ou non ciblé.

Dans l’empoisonnement ciblé du modèle, un attaquant contaminerait l’ensemble de données d’entraînement/le modèle de base de l’IA, ce qui entraînerait une porte dérobée pouvant être activée par une entrée arbitraire pour obtenir une sortie particulière qui fonctionne correctement avec les entrées attendues. La contamination pourrait être une petite perturbation qui n’affecte pas le fonctionnement attendu (comme la précision du modèle, les vitesses d’inférence, etc.) du modèle et donnerait l’impression qu’il n’y a pas de problèmes.

Cela ne nécessite pas non plus que l’attaquant saisisse et déploie un clone du système de formation pour vérifier l’opération, car le système lui-même était contaminé et affecterait de manière omniprésente tout système utilisant le modèle/l’ensemble de données empoisonné.

L’empoisonnement non ciblé du modèle, ou attaques byzantines, se produit lorsque l’attaquant a l’intention de réduire les performances (précision) du modèle et stagne l’entraînement. Cela nécessiterait de revenir à un point avant que le modèle/l’ensemble de données n’ait été compromis (potentiellement depuis le début).

Outre la formation hors ligne, l’apprentissage fédéré, une technique dans laquelle les données collectées à partir des terminaux sont utilisées pour recycler/améliorer le modèle cloud, est intrinsèquement vulnérable en raison de la nature décentralisée de son traitement. Cela permet aux attaquants de participer à des terminaux compromis, ce qui compromet le modèle cloud. Cela pourrait avoir de grandes implications car ce même modèle de cloud pourrait être utilisé sur des millions d’appareils.

Pendant la phase d’inférence, un pirate peut opter pour la technique d’évasion de modèle où il interroge de manière itérative le modèle (par exemple, une image) et ajoute du bruit à l’entrée pour comprendre comment le modèle se comporte. De cette manière, le pirate pourrait potentiellement obtenir une sortie spécifique/requise (c’est-à-dire une décision logique après avoir réglé son entrée suffisamment de fois sans utiliser l’entrée attendue). Une telle interrogation pourrait également être utilisée pour l’inversion de modèle, où les informations sur le modèle ou les données d’apprentissage sont extraites de la même manière.

Analyse des risques lors du développement d’AI TinyML

Pour la phase d’inférence, les attaques contradictoires contre les modèles d’IA sont un domaine de recherche actif, où les universités et l’industrie se sont alignées pour travailler sur ces questions et ont développé le paysage des menaces contradictoires pour les systèmes d’intelligence artificielle (ATLAS), qui est une matrice qui permettrait analystes en cybersécurité pour évaluer le risque pour leurs modèles. Il comprend également des cas d’utilisation dans l’ensemble de l’industrie, y compris l’IA de pointe.

L’apprentissage des études de cas fournies fournira aux développeurs/propriétaires de produits une compréhension de la manière dont ATLAS affecterait leur cas d’utilisation, évaluera les risques et prendra des mesures de sécurité supplémentaires pour atténuer les inquiétudes des clients. Les modèles d’IA doivent être considérés comme sujets à de telles attaques et une évaluation minutieuse des risques doit être menée par diverses parties prenantes.

Pour la phase de formation, s’assurer que les ensembles de données et les modèles proviennent de sources fiables réduirait le risque d’empoisonnement des données/modèles. Ces modèles/données doivent généralement être fournis par des éditeurs de logiciels fiables. Un modèle d’apprentissage automatique peut également être formé avec la sécurité à l’esprit, ce qui rend le modèle plus robuste, comme une approche de force brute de formation contradictoire où le modèle est formé sur de nombreux exemples contradictoires et apprend à se défendre contre eux.

Cleverhans, une bibliothèque de formation open source, est utilisée pour construire de tels exemples pour attaquer, défendre et comparer un modèle d’attaques contradictoires. La distillation de défense est une autre méthode où un modèle est formé à partir d’un modèle plus grand pour produire des probabilités de différentes classes, plutôt que des décisions difficiles rendant plus difficile pour l’adversaire d’exploiter le modèle. Cependant, ces deux méthodes peuvent être décomposées avec une puissance de calcul suffisante.

Protégez votre adresse IP IA

Parfois, les entreprises peuvent s’inquiéter de l’intention malveillante de leurs concurrents de voler l’IP/la fonctionnalité du modèle qui est stockée sur un appareil sur lequel l’entreprise a dépensé son budget de R&D. Une fois le modèle formé et peaufiné, il devient un exécutable binaire stocké sur le MCU et peut être protégé par les mesures de sécurité IoT conventionnelles, telles que la protection des interfaces physiques avec la puce, le cryptage des logiciels et l’utilisation de TrustZone.

Une chose importante à noter, cependant, est que même si l’exécutable binaire était volé, ce n’est que le modèle final poli qui est conçu pour un cas d’utilisation spécifique qui peut être facilement identifié comme une violation du droit d’auteur. Par conséquent, l’ingénierie inverse nécessiterait plus d’efforts que de commencer avec un modèle de base à partir de zéro.

De plus, dans le développement de TinyML, les modèles d’IA ont tendance à être bien connus et à source ouverte, comme MobileNet, qui peut ensuite être optimisé grâce à une variété d’hyperparamètres. Les ensembles de données, en revanche, sont conservés en toute sécurité car ce sont des trésors précieux que les entreprises dépensent en ressources pour acquérir et qui sont spécifiques à un cas d’utilisation donné. Cela pourrait inclure l’ajout de cadres de délimitation aux régions d’intérêt dans les images.

Des ensembles de données généralisées sont également disponibles en open source, comme CIFAR, ImageNet et autres. Ils sont suffisants pour comparer différents modèles, mais des ensembles de données sur mesure doivent être utilisés pour le développement de cas d’utilisation spécifiques. Dans le cas d’un mot d’avertissement visuel dans un environnement de bureau, un ensemble de données isolé dans un environnement de bureau donnerait le résultat optimal.

Cet article a été initialement publié leTemps EE.