- Le projet de sécurité matérielle du MIT, en reproduisant dans un navigateur web une attaque par canal auxiliaire assistée par apprentissage automatique, a mis en évidence un piège : une forte précision du modèle ne prouve pas la cause réelle
- Les recherches existantes sur le fingerprinting de sites web attribuaient la cause à la contention du cache CPU, mais une méthode supprimant les accès au cache et se contentant d’incrémenter un compteur simple a obtenu une précision plus élevée dans plusieurs environnements
- L’équipe a successivement écarté la mise à l’échelle de la fréquence CPU, la contention entre cœurs CPU et l’hypothèse du cache ; avec une instrumentation eBPF, elle a confirmé que plus de 99 % des pauses de 100 ns ou plus correspondaient au traitement d’interruptions
- Les seuls signaux d’interruptions système révélaient l’activité de chargement des sites web ; sous Chrome/Linux, la précision d’identification du site victime parmi 100 sites web a atteint 96,6 %
- Pour concevoir des défenses, il faut d’abord analyser le mécanisme réel du canal auxiliaire, plutôt que se contenter du fait que le modèle a correctement prédit
À l’origine de la recherche
- En 2020, dans le cours Secure Hardware Design du MIT, un projet a été lancé pour réimplémenter une attaque de fingerprinting de sites web, en s’appuyant sur une expérience en développement web et en apprentissage automatique
- Mengjia Yan estimait que quelque chose clochait dans les recherches récentes sur le fingerprinting de sites web qui utilisent l’apprentissage automatique pour exploiter des faiblesses matérielles, et a proposé de les reproduire
- Le projet a ensuite donné lieu à l’article There’s Always a Bigger Fish: A Clarifying Analysis of a Machine-Learning-Assisted Side-Channel Attack
- L’article a remporté la première place du 2024 Hardware Security Academic Award d’Intel et a été sélectionné dans les IEEE Micro Top Picks 2023
- La recherche s’articule autour de trois axes : attaques via le navigateur, fuites par interruptions système et erreurs d’interprétation de l’apprentissage automatique
Canaux auxiliaires et fingerprinting de sites web
- L’isolation des processus sépare la mémoire et les ressources des applications, mais dans un ordinateur réel, des ressources comme la carte réseau, le GPU et le CPU restent partagées en permanence
- Les ressources partagées peuvent divulguer involontairement des informations sur l’activité de l’utilisateur
- Si une personne utilisant le même routeur Wi‑Fi regarde une vidéo volumineuse, les téléchargements des autres utilisateurs peuvent ralentir
- Les variations de consommation électrique ou les émissions électromagnétiques peuvent aussi devenir des canaux auxiliaires permettant d’inférer des clés de chiffrement ou l’activité d’un utilisateur
- Le fingerprinting de sites web est une attaque dans laquelle un site web attaquant ouvert dans un onglet cherche à identifier le site web victime ouvert dans un autre onglet
- Les travaux antérieurs de Shusterman et al. présentaient une attaque utilisant le cache CPU pour deviner quel site était ouvert parmi 100 sites candidats
- L’attaquant crée un tableau de la taille du cache CPU et le remplit avec des 1
- Pendant le chargement du site web victime, il mesure le temps d’accès au tableau toutes les 2 ms
- Il collecte au total 7 500 mesures sur 15 secondes
- Comme les scripts, images, feuilles de style et schémas de rendu se répètent de manière similaire pour chaque site web, la trace de mesures sert d’empreinte
- En collectant 100 traces pour chacun des 100 sites web, il construit un jeu de données étiqueté de 10 000 exemples et entraîne un modèle d’apprentissage automatique
- Il obtient jusqu’à 91,4 % de précision sur plusieurs navigateurs et systèmes d’exploitation
Une attaque par compteur sans cache
- Lors de la première réimplémentation, la classification de 4 sites web était facile, et un simple classifieur Random Forest obtenait 98 % de précision
- En étendant l’expérience à 10 sites web, la précision était d’abord de 75 %, puis elle a été améliorée jusqu’à la classification de 10, 50 et 100 sites web
- Le changement décisif a consisté à supprimer l’accès au tableau du cache et à faire en sorte que l’attaquant répète
value++aussi vite que possible- En enregistrant la valeur du compteur à intervalles réguliers, on obtient une trace de la quantité d’exécution de l’ordinateur pendant cette période
- D’autres activités, comme redimensionner la fenêtre du navigateur ou ouvrir un nouvel onglet, se reflètent aussi dans la trace du compteur
- Dans l’article, la valeur est enregistrée toutes les 5 ms afin d’obtenir davantage d’informations dans un temps fixe
- Le modèle entraîné sur les traces du compteur affiche une précision d’identification des sites web plus élevée que celui fondé sur les traces de latence du cache
- Ce résultat a soulevé la question de savoir si l’attaque existante exploitait réellement la contention du cache, et a conduit à une analyse visant à en trouver la cause
L’écart entre précision du modèle et analyse causale
- Dans une attaque par canal auxiliaire assistée par apprentissage automatique, le fait qu’un modèle prédise de manière fiable l’activité d’un utilisateur ne montre que l’existence d’un signal
- Une forte précision ne prouve pas de quel canal auxiliaire provient ce signal
- Même si le modèle de Shusterman et al. identifie le site web victime avec 91,4 % de précision, cela ne signifie pas qu’il a capté une contention du cache CPU
- Ce que le modèle trouve, ce sont des corrélations ; il n’explique pas la cause du signal
- Une mauvaise analyse causale peut induire en erreur la conception de défenses
- Les chercheurs conçoivent des défenses pour rendre les ordinateurs plus sûrs à partir d’articles d’attaque
- Si la cause de l’attaque est mal comprise, du temps et des efforts peuvent être gaspillés
Vérification des hypothèses : fréquence, cœur, interruptions
- L’équipe a comparé l’attaque existante fondée sur le cache et la nouvelle attaque fondée sur un compteur dans plusieurs environnements
- Dans la tâche d’identification de 100 sites web, l’attaque fondée sur le compteur a obtenu une précision plus élevée dans presque toutes les configurations expérimentales
- Sur Safari sous macOS, l’attaque par cache a affiché 72,6 % de précision, contre 96,6 % pour l’attaque par compteur
- Dans la configuration par défaut, le bon site parmi 100 a été identifié avec 95,2 % de précision
-
Hypothèse de la mise à l’échelle de la fréquence CPU
- Les CPU modernes économisent de l’énergie en augmentant ou diminuant leur fréquence selon la charge de travail
- L’hypothèse était que la fréquence CPU pouvait changer pendant le chargement du site web victime et modifier la valeur du compteur
- Après avoir désactivé la mise à l’échelle de la fréquence dans le BIOS, l’équipe a collecté de nouvelles données et entraîné le modèle
- La précision n’a baissé que d’un point, de 95,2 % à 94,2 %, ce qui rendait difficile d’expliquer les variations du compteur par des changements de fréquence CPU
-
Hypothèse de la contention entre cœurs CPU
- Si l’attaquant et l’onglet victime s’exécutent sur le même cœur CPU, le chargement de l’onglet victime peut réduire le temps d’exécution du compteur de l’attaquant
- Avec
tasksetsous Linux, l’équipe a fixé l’attaquant et l’onglet victime sur des cœurs différents - Même avec la mise à l’échelle de la fréquence CPU désactivée, la précision est restée à 94,0 %
- La contention entre cœurs CPU semblait donc difficile à considérer comme cause principale
-
Hypothèse des interruptions système
- L’hypothèse suivante était que les interruptions système constituaient le signal de l’attaque par compteur
- Le système d’exploitation utilise des interruptions pour communiquer avec des périphériques matériels comme le clavier, la souris, l’écran et la carte réseau
- Lorsqu’une interruption arrive sur un cœur CPU, le programme en cours d’exécution sur ce cœur s’arrête immédiatement et le gestionnaire d’interruption s’exécute
- Pendant le chargement du site web victime, divers périphériques, notamment réseau et graphiques, génèrent des interruptions ; si elles sont traitées sur le même cœur que l’attaquant, la valeur de son compteur peut diminuer
- Sous Linux,
cat /proc/interruptspermet d’observer le traitement des interruptions
Interruptions déplaçables et non déplaçables
- Linux peut router certaines interruptions déplaçables vers un cœur spécifique
- Les interruptions dotées d’un ID numérique relèvent de cette catégorie
- Elles proviennent souvent de périphériques matériels externes comme le clavier ou la carte réseau
- Beaucoup d’interruptions non déplaçables ne peuvent pas être isolées sur un cœur spécifique
- Les interruptions dotées d’un ID de trois lettres relèvent de cette catégorie
- Elles servent à synchroniser l’activité entre cœurs CPU et doivent donc être traitées sur tous les cœurs
- Dans l’environnement expérimental, elles représentaient la majeure partie de l’activité d’interruption
- Avec
irqbalance, les interruptions déplaçables ont été envoyées vers le cœur 1, et avectaskset, l’attaquant et la victime ont été exécutés sur les cœurs 2 et 3 - Avec la fréquence CPU également fixée, la précision a chuté de près de 6 points, rendant l’hypothèse des interruptions plus probable
La cause réelle confirmée avec eBPF
- Comme il était impossible, en raison de la structure du système d’exploitation, de mener une expérience isolant complètement même les interruptions non déplaçables, l’exécution a été instrumentée avec eBPF
- eBPF a permis d’enregistrer deux types de moments
- Le moment où le programme attaquant démarre et s’arrête
- Le moment où le gestionnaire d’interruption démarre et s’arrête
- Comme la fréquence CPU est fixe, l’attaquant devrait exécuter presque le même nombre d’instructions dans un temps donné s’il n’est pas interrompu
- Le code eBPF écrit par Jonathan Behrens a été utilisé pour comparer les périodes où l’attaquant était suspendu et les périodes de traitement des interruptions
- Plus de 99 % des interruptions d’exécution de l’attaquant durant 100 ns ou plus se sont révélées être du temps de traitement d’interruptions
- Le cœur CPU de l’attaquant exécutait en pratique soit le code de comptage, soit le traitement d’interruptions ; un temps de traitement d’interruptions plus faible faisait monter la valeur du compteur, tandis qu’un temps plus élevé la faisait baisser
Les deux principaux résultats de l’article
- Le premier résultat est que les interruptions système divulguent l’activité utilisateur
- Les propriétés de sécurité des interruptions système n’avaient pas été étudiées dans la littérature existante
- L’équipe a réalisé la première analyse d’un canal auxiliaire fondé sur les interruptions système
- Le second résultat est qu’il faut analyser avec prudence les attaques par canal auxiliaire assistées par apprentissage automatique
- Un modèle d’apprentissage automatique peut produire une attaque puissante sans comprendre le canal auxiliaire
- Sans instrumentation du système d’exploitation, il aurait été impossible de conclure quel canal auxiliaire était utilisé
- Les défenses existantes contre l’attaque fondée sur le cache consistaient à expulser de manière répétée les lignes du cache CPU pour ajouter du bruit
- Une défense générant de nombreuses interruptions, par exemple en envoyant des requêtes réseau vers une adresse IP locale, fonctionne mieux contre les attaques fondées sur le cache comme sur le compteur
- Cette comparaison renforce l’hypothèse selon laquelle l’attaque de Shusterman et al. utilise principalement un signal d’interruptions plutôt qu’un signal de cache
Expériences supplémentaires et possibilités de défense
- L’article inclut aussi des résultats supplémentaires
- Il propose une méthode pour atténuer complètement l’attaque en modifiant l’horloge fournie à JavaScript par le navigateur
- Il mène une expérience d’isolation plaçant l’attaquant et la victime dans des machines virtuelles distinctes
- Il analyse la fréquence et le temps de traitement de plusieurs interruptions non déplaçables
- Les navigateurs réduisent la précision de l’horloge fournie à JavaScript afin de rendre les attaques fondées sur un timing de haute précision plus difficiles
- Chrome arrondit à 0,1 ms et ajoute un bruit aléatoire
- Firefox et Safari arrondissent à 1 ms
- Tor Browser arrondit à 100 ms, faisant chuter la précision de l’attaque de 96,6 % sous Chrome à 49,8 %
- La réduction de la précision de l’horloge implique des compromis
- Les moteurs de jeux basés sur le navigateur ont besoin de minuteurs de haute précision pour le rendu et les animations
- Les utilisateurs de Tor Browser ont du mal à jouer à la plupart des jeux, mais cela peut ne pas être un problème pour des utilisateurs qui privilégient la sécurité
Questions de recherche restantes
- Les interruptions système sont liées à des mécanismes matériels profondément ancrés dans les ordinateurs modernes, comme Spectre et Meltdown
- Les défenses isolant les interruptions non déplaçables de l’attaquant ne peuvent pas être mises en œuvre aujourd’hui, et on ne sait pas clairement comment il faudrait reconcevoir les ordinateurs pour les rendre possibles
- La relation entre l’activité des sites web et les interruptions n’est pas non plus suffisamment comprise
- weather.com a déclenché de nombreuses rescheduling interrupts, contrairement à nytimes.com et amazon.com
- L’effet des images, publicités et scripts supplémentaires sur les traces du compteur n’a pas été analysé
- L’attaque pourrait devenir plus puissante
- L’article ressemble davantage à un « article d’analyse » qu’à un « article d’attaque »
- La précision de 96,6 % obtenue sous Chrome/Linux pourrait être une borne inférieure, et non supérieure
- De meilleurs modèles ou d’autres méthodologies pourraient encore être appliqués à des tâches comme classifier 1 000 sites web, déterminer si un film est regardé, si un VPN est utilisé ou à quelle fréquence Robinhood est consulté
- Les défenses côté navigateur doivent aussi être implémentées dans de vrais navigateurs et évaluées quant à leur praticité pour les utilisateurs ordinaires
L’impact de cette recherche sur un parcours personnel
- Avant ce projet, les études supérieures n’étaient pas une option envisagée sérieusement ; après une expérience de stagiaire en recherche en deep learning chez NVIDIA, l’idée était plutôt de rejoindre une grande entreprise tech ou une startup IA
- Après le projet, la recherche est apparue comme quelque chose de plaisant et de beau
- Après le MIT, un cursus MEng en informatique a été poursuivi pendant un an, puis une Rhodes scholarship a permis d’étudier pendant deux ans à l’University of Oxford
- Un PhD de six ans en informatique au MIT doit commencer l’année suivante
1 commentaires
Commentaires de Hacker News
Bon article, et la recherche derrière est soignée.
À mon avis, l’apport de l’article n’a en réalité pas grand-chose à voir avec le machine learning, mais plutôt avec la découverte d’un nouveau canal auxiliaire utilisant les interruptions.
Ici, le machine learning sert surtout à attirer davantage les lecteurs ; parler de « statistiques » n’aurait probablement pas changé grand-chose.
Cela me rappelle ce que mon ancien directeur de thèse disait : « Une fois que vous comprenez de quoi parle vraiment votre article, réécrivez-le en retirant ce que vous pensiez auparavant être le sujet. »
Je pense que le titre de cet article aurait dû mettre l’accent sur le nouveau canal auxiliaire plutôt que sur le machine learning. Mais c’est du pinaillage : c’est un excellent travail.
La découverte de cette mauvaise interprétation du machine learning est particulièrement importante parce qu’elle remet en question une bonne partie de la recherche en architecture des ordinateurs existante.
Auparavant, pour mener ce type d’attaque, il fallait comprendre en profondeur le canal auxiliaire exploité ; mais les modèles de machine learning, ici un LSTM, permettent une précision bien supérieure à de simples « statistiques » et facilitent la création d’attaques puissantes exploitant des canaux auxiliaires mal compris.
Il existe aujourd’hui pas mal d’attaques assistées par machine learning construites de cette manière, et le seul article de Shusterman et al. a reçu près de 200 citations, un chiffre énorme pour un article d’architecture des ordinateurs.
Le but de publier ce type de recherche est de mieux comprendre les systèmes afin de construire des défenses plus solides, et le coût d’une mauvaise compréhension qui induit la communauté en erreur est élevé.
Cela resterait vrai même si la cause de l’attaque précédente s’était finalement révélée être le cache, mais la découverte d’un nouveau canal auxiliaire au passage rend le message beaucoup plus clair. Le billet de blog aurait sans doute pu insister davantage sur ce point.
Dans la réalité, quand on se noie dans un océan de données, ce bon sens peut se perdre dans un déluge de corrélations, mais une bonne conception expérimentale et la relecture par les pairs sont censées filtrer les conclusions et interprétations fragiles.
De ce point de vue, cette étude de reproduction a très bien fait son travail.
Excellent article. Je ne pensais pas qu’une attaque par canal auxiliaire pouvait être rendue aussi facile à comprendre.
On sait dès le début qui est le méchant, mais cela se lit comme un polar où l’on cherche à découvrir « comment il a fait ».
Ajouté aux favoris.
Mais c’est grâce à cette réaction que je l’ai lu, et c’était effectivement vraiment très bon.
Le passage « L’an prochain, je retourne au MIT pour commencer un doctorat de six ans en informatique. Je ne pourrais pas être plus enthousiaste ! » est surprenant.
Ce qui est frappant, c’est que tout a commencé par une idée chanceuse de l’autrice : au lieu de l’attaque d’éviction de cache bien plus sophistiquée de l’attaque par canal auxiliaire d’origine, essayer au hasard d’utiliser un compteur, et que cela ait fonctionné grâce à des notions qu’elle ne connaissait pas encore à l’époque.
Quelqu’un comme moi, probablement parmi des milliers d’autres, n’a pas eu cette chance ; j’ai rapidement abandonné l’idée de rester dans le monde académique et je suis parti dans l’industrie pour y mener une carrière ordinaire.
J’avais commencé un Honours Degree australien en informatique, quelque chose d’assez proche d’un master, et vers 2010, bien avant l’engouement actuel pour l’IA, je voulais écrire un article sur l’intelligence artificielle à partir des cas d’usage appris dans un cours formel d’IA.
Je voulais partir de la façon dont les domaines viticoles utilisaient l’IA pour améliorer la qualité et la production du vin, puis appliquer cela à des usages plus « généraux », mais le directeur qui m’a été attribué n’avait absolument aucune envie de m’aider, et sans autre soutien il était difficile de continuer.
D’autant que j’avais une offre de CDI assez bien payée, et même si j’avais poursuivi, je n’aurais probablement pas produit grand-chose.
Comme le dit l’autrice, les choses ont marché grâce à son directeur et à l’aide autour d’elle ; seul, il faut une énergie et un talent énormes, et je crois que je manquais des deux.
Lors de mon premier doctorat au Japon, mon professeur et les personnes autour de moi ont passé trois ans à critiquer chacune de mes propositions sans jamais avancer d’idée réalisable.
Le professeur du laboratoire voisin aimait mes recherches, mais je l’ai appris trop tard pour changer de laboratoire.
Aujourd’hui, je suis dans un endroit où je peux travailler avec la moitié des personnes du pays capables de comprendre pleinement mon autre projet et de s’en soucier, soit deux personnes au total, et leurs données ont déjà amélioré le projet.
Le directeur m’apprécie aussi et m’inclut dans les activités du labo, même si je n’y suis pas officiellement rattaché.
Dans un tel environnement, on peut réussir. Trouver le bon environnement et les bonnes personnes est difficile mais décisif ; sans cela, même un très bon travail peut finir en efforts perdus.
L’article était bon.
Tout petit pinaillage lié à la page : le style de séparateur fait de gros points alignés m’a dérouté, car il ressemble à un indicateur de position dans un carrousel d’images.
L’article est excellent, l’explication très accessible, et les démos interactives sont vraiment super.
J’ai aussi apprécié le contexte sur la façon dont elle en est venue à travailler sur ce sujet.
Très intéressant et bien expliqué. Si la recherche date d’il y a deux ans, les collecteurs de données intéressés l’ont probablement déjà prise en compte.
Oubliez les hackers. C’est un exploit pour les entreprises et les gouvernements.
Un site web soucieux de la protection de la vie privée pourrait-il distribuer un paquet qui déclenche des interruptions aléatoires ? Une extension de navigateur pourrait-elle le faire pour tous les sites ?
Notre contre-mesure qui déclenche des interruptions aléatoires est implémentée sous forme d’extension de navigateur, et le code source est ici : https://github.com/jackcook/bigger-fish
Cela dit, il est difficile de la recommander pour un usage quotidien. Dans nos tests, si je me souviens bien, les temps de chargement des pages étaient ralentis d’environ 10 %.
Certaines changeaient pas mal lorsque l’ordinateur était très sollicité, mais il est possible que Safari intègre déjà certaines mesures d’atténuation.
L’article reste vraiment excellent.