TL;DR — En résumé
GPU side-channels : cache timing CUDA, keystroke inference, extraction modèle ML, attaques WebGL/WebGPU. Défenses et isolation GPU. Guide expert.
Les GPU (Graphics Processing Units) sont devenus des composants critiques au-delà du rendu graphique : intelligence artificielle, calcul scientifique, cryptographie, et même l'exécution de navigateurs web. Cette omniprésence crée de nouvelles surfaces d'attaque : les attaques par canaux auxiliaires GPU exploitent les fuites d'information à travers les caches GPU, les compteurs de performance, la consommation mémoire et les temps d'exécution des kernels CUDA et OpenCL. Les chercheurs ont démontré l'extraction de clés cryptographiques, le keystroke timing via le rendu GPU, et l'espionnage de modèles de machine learning via les side-channels GPU. Ce guide technique couvre l'architecture des GPU du point de vue sécurité, les vecteurs d'attaque spécifiques aux GPU NVIDIA et AMD, les techniques d'exploitation pratiques et les contre-mesures disponibles.
En bref
- Architecture GPU : caches L1/L2, shared memory, warp scheduling et vecteurs de fuite
- Attaques timing : keystroke timing via GPU rendering, website fingerprinting
- Attaques cache GPU : Flush+Reload adapté au cache L2 GPU, covert channels
- Espionnage de modèles ML : extraction d'architecture et de paramètres via le timing GPU
- Side-channels WebGL/WebGPU : attaques depuis le navigateur sans privilèges
Architecture GPU : Perspective Sécurité
Les GPU modernes (NVIDIA, AMD, Intel) ont une architecture massivement parallèle avec des milliers de cœurs. Du point de vue sécurité, les composants partagés entre les applications créent des canaux de fuite :
| Composant GPU | Partagé entre | Type de fuite |
|---|---|---|
| Cache L2 | Tous les kernels/contextes | Cache timing (Flush+Reload) |
| Shared Memory / LDS | Threads d'un même block | Bank conflicts timing |
| Memory bandwidth | Tous les contextes | Contention monitoring |
| Performance counters | Global (certains GPUs) | Activité monitoring |
| Warp/Wavefront scheduler | SM/CU | Scheduling timing |
| TLB GPU | Tous les contextes | TLB timing side-channel |
Attaques Cache sur GPU NVIDIA
Les GPU NVIDIA utilisent un cache L2 partagé entre tous les contextes CUDA. Les chercheurs ont adapté les techniques de Prime+Probe et Flush+Reload au cache L2 GPU pour créer des canaux de communication cachés (covert channels) et extraire des informations sur les calculs d'autres processus :
// Prime+Probe sur cache L2 GPU (CUDA)
// Étape 1: PRIME — remplir le cache L2 avec nos données
__global__ void prime_cache(int *probe_array, int stride, int sets) {
for (int s = 0; s < sets; s++) {
// Accéder à chaque set du cache L2
volatile int val = probe_array[s * stride];
}
}
// Étape 2: PROBE — mesurer les temps d'accès après que la victime a exécuté
__global__ void probe_cache(int *probe_array, int stride, int sets,
clock_t *timings) {
for (int s = 0; s < sets; s++) {
clock_t start = clock();
volatile int val = probe_array[s * stride];
clock_t end = clock();
timings[s] = end - start;
// Si timing élevé → la victime a évicté notre ligne de cache
// → la victime a accédé à un set correspondant
}
}
Keystroke Timing via GPU Rendering
Une attaque élégante exploite le fait que chaque frappe clavier déclenche un cycle de rendu GPU (mise à jour de l'écran). En surveillant l'activité GPU depuis un processus non privilégié (via les compteurs de performance ou la contention mémoire), un attaquant peut détecter le timing des frappes clavier avec une précision de quelques millisecondes — suffisant pour réduire l'espace de recherche des mots de passe et identifier les mots tapés.
Espionnage de Modèles de Machine Learning
Les modèles de ML s'exécutent principalement sur GPU. Les side-channels GPU permettent d'extraire des informations sur les modèles propriétaires (architecture, nombre de couches, taille) sans accès direct :
- Timing d'inférence : le temps d'exécution d'un kernel CUDA révèle le nombre d'opérations et la taille des matrices — permettant de déduire l'architecture du réseau de neurones
- Memory footprint : la consommation mémoire GPU pendant l'inférence indique le nombre de paramètres et la taille des activations
- Electromagnetic emanations : les émissions EM du GPU varient selon les opérations effectuées — des chercheurs ont reconstruit les poids d'un réseau de neurones à partir des mesures EM
- Cache contention : les patterns d'accès au cache L2 GPU pendant l'inférence révèlent les structures de données et les patterns d'accès mémoire du modèle
Attaques via WebGL et WebGPU
Les API web WebGL et WebGPU donnent aux pages web un accès au GPU — créant des vecteurs d'attaque side-channel depuis le navigateur sans aucun privilège :
- GPU-based browser fingerprinting : les variations de rendu GPU entre les modèles de GPU créent une empreinte unique, identifiable via WebGL. DrawnApart (2022) obtient une précision de 98% pour le tracking entre sessions.
- WebGL timing attacks : mesurer le temps de rendu de shaders spécifiques pour détecter l'activité d'autres onglets (site visité, vidéo en cours, etc.)
- GPU.zip (2023) : compression de données dépendante du contenu dans les GPU modernes, exploitable via iframes cross-origin en CSS pour lire des pixels d'autres origines — contournement de la same-origin policy.
Mitigations et Isolation GPU
- MIG (Multi-Instance GPU) : NVIDIA A100/H100 permettent le partitionnement matériel du GPU en instances isolées avec des caches et mémoire séparés
- NVIDIA Confidential Computing : chiffrement de la mémoire GPU (H100 TEE) pour protéger les données des modèles ML
- GPU virtualization (SR-IOV) : isolation via les fonctions virtuelles PCIe — chaque VM a un accès GPU isolé
- WebGPU security model : validation des shaders, limites de timing, et isolation des contextes entre onglets
À retenir
- Le cache L2 GPU partagé entre contextes permet des attaques Prime+Probe adaptées au GPU
- Le keystroke timing via monitoring GPU détecte les frappes clavier avec une précision millisecondes
- Les modèles ML sont vulnérables à l'extraction d'architecture via le timing et la mémoire GPU
- WebGL/WebGPU permettent des side-channels GPU depuis le navigateur sans aucun privilège
- GPU.zip (2023) contourne la same-origin policy via la compression GPU hardware
- MIG et le confidential computing GPU (H100 TEE) sont les principales mitigations d'isolation
FAQ — Questions Fréquentes
Les side-channels GPU sont-ils exploitables à distance ?
Oui, les attaques via WebGL/WebGPU sont exploitables à distance depuis une page web — aucun accès physique ni privilège nécessaire. Les attaques GPU.zip et le browser fingerprinting via WebGL fonctionnent depuis n'importe quel navigateur supportant WebGL. En environnement cloud, les side-channels GPU affectent les co-tenants partageant le même GPU physique.
Comment protéger mes modèles ML sur GPU partagé ?
Utilisez des GPU dédiés (pas de time-sharing), activez MIG sur les GPU NVIDIA supportés (A100, H100), ou utilisez le confidential computing GPU (H100 TEE) qui chiffre la mémoire GPU. Ajoutez du bruit aux timings d'inférence et randomisez les patterns d'accès mémoire pour réduire les fuites side-channel.
Les GPU AMD sont-ils aussi vulnérables ?
Oui, les GPU AMD partagent les mêmes principes architecturaux (caches partagés, shared memory) et sont vulnérables aux mêmes classes d'attaques. Les recherches se concentrent sur NVIDIA (part de marché dominante en ML/cloud), mais les techniques sont transposables à AMD et Intel. AMD n'a pas encore d'équivalent au MIG pour l'isolation matérielle.
Besoin d'un accompagnement expert ?
Nos consultants spécialisés en sécurité matérielle et IA vous accompagnent dans l'évaluation de votre posture de sécurité.
Contactez-nous📚 Articles connexes
🔗 Références externes

Besoin d'un expert cybersécurité ?
Audit, pentest, formation, IA — plus de 25 ans d'expérience, 100+ missions réalisées.
GPU side-channels : de la théorie aux attaques pratiques
Les attaques par canaux auxiliaires GPU ont longtemps été considérées comme des curiosités académiques, trop complexes et trop peu pratiques pour menacer des systèmes réels. Les recherches de 2023-2026 ont réfuté cette hypothèse. Des attaques pratiques démontrent l'extraction de clés cryptographiques, la reconstruction de contenu d'écran et le vol de données de modèles IA depuis des GPU partagés.
Canaux auxiliaires GPU : les vecteurs techniques
Les GPU exposent plusieurs canaux d'information exploitables pour des attaques side-channel, différents de ceux des CPU :
- Contention sur les unités de calcul (Shader Units) : dans un environnement de GPU partagé (cloud GPU, conteneurs avec accès GPU), plusieurs processus partagent les shader units. Les variations de latence d'accès aux ressources de calcul révèlent des informations sur le workload des autres processus partageant le GPU.
- Cache de texture et L1/L2 GPU : analogues aux attaques FLUSH+RELOAD et PRIME+PROBE sur CPU, des attaques sur les caches GPU permettent de déduire les patterns d'accès mémoire d'un processus concurrent. Les GPU modernes disposent de plusieurs niveaux de cache (L1 par SM, L2 partagé) avec des caractéristiques d'accès exploitables.
- Consommation électrique (Power Side-Channel) : les GPU exposent des compteurs de performance accessibles via NVML (NVIDIA Management Library) qui révèlent des informations sur l'activité de calcul. Des variations de consommation électrique corrélées avec des opérations cryptographiques peuvent révéler des secrets.
- Canaux de communication inter-GPU : dans les architectures multi-GPU avec NVLink, les patterns de communication entre GPU peuvent révéler des informations sur la topologie du modèle IA entraîné ou sur les données traitées.
Attaques démontrées sur des environnements cloud GPU
Plusieurs attaques side-channel GPU pratiques ont été démontrées dans des environnements cloud réalistes :
- PixelSteal (2023, CU Boulder) : démonstration d'une attaque qui reconstruit partiellement le contenu d'une fenêtre de navigateur affichée par un autre processus sur le même GPU, en exploitant la contention sur les ressources GPU partagées. Impact direct sur la confidentialité des sessions navigateur dans les environnements de desktop virtuel avec GPU partagé.
- GPU.zip (2024) : exploitation de la compression graphique intégrée des GPU (DCC - Delta Color Compression) pour extraire des informations sur les pixels rendus par d'autres processus. Cette attaque démontre que des optimisations de performance GPU introduisent involontairement des canaux d'information exploitables.
- Vol de modèles IA via side-channel : des recherches de 2025 démontrent qu'il est possible d'inférer l'architecture et partiellement les paramètres d'un modèle IA tournant sur un GPU partagé en observant les patterns de contention sur les ressources de calcul. Les implications pour la propriété intellectuelle des modèles sont significatives.
CUDA et OpenCL : surfaces d'attaque spécifiques
Les frameworks de programmation GPU (CUDA d'NVIDIA, OpenCL, ROCm d'AMD) introduisent des surfaces d'attaque spécifiques au-delà des side-channels hardware :
- Isolation insuffisante de la mémoire GPU entre processus : des recherches ont démontré que sur certaines configurations, la mémoire GPU allouée par un processus et libérée n'est pas systématiquement effacée avant d'être réallouée à un autre processus. Un processus malveillant peut lire des données résiduelles de processus précédents dans la mémoire GPU.
- Accès aux performance counters via CUPTI : NVIDIA CUDA Profiling Tools Interface (CUPTI) expose des compteurs de performance très granulaires qui peuvent être lus par n'importe quel processus avec accès GPU dans certaines configurations. Ces compteurs révèlent des informations sur le workload des autres processus.
- Vulnérabilités dans les pilotes GPU : les pilotes GPU (NVIDIA driver, AMD AMDGPU) sont des composantes kernel-mode complexes avec une surface d'attaque importante. Des CVE critiques dans les pilotes GPU permettent une escalade de privilèges vers ring-0 depuis un contexte non privilégié.
Contre-mesures pour les environnements GPU partagés
Pour les organisations qui utilisent des GPU partagés (cloud GPU, serveurs de ML avec accès multi-utilisateurs), voici les mesures à considérer :
- Isolation de GPU (GPU partitioning) : les GPU modernes (NVIDIA A100, H100) supportent le MIG (Multi-Instance GPU) qui partitionne physiquement le GPU en instances isolées avec mémoire et ressources de calcul dédiées. Cette isolation élimine les vecteurs de contention et de mémoire résiduelle entre instances.
- Évaluation des scénarios de menace pour les workloads sensibles : les modèles IA propriétaires, les données d'entraînement confidentielles et les calculs cryptographiques doivent être réservés à des GPU dédiés, pas partagés dans des environnements multi-tenants.
- Mise à jour des pilotes GPU : les vulnérabilités dans les pilotes NVIDIA et AMD sont régulièrement corrigées. Les pilotes GPU doivent être intégrés dans le programme de gestion des vulnérabilités au même titre que les autres composants système.
- Monitoring des accès CUPTI : restreindre l'accès à CUPTI aux processus qui en ont explicitement besoin (outils de profiling légitimes). L'accès non autorisé aux compteurs de performance GPU est un signal d'alerte.
Foire aux questions — GPU side-channels et sécurité
Les GPU side-channels sont-ils exploitables sans accès physique ?
Dans des environnements cloud GPU partagés (AWS EC2 GPU, Google Cloud GPU, Azure NCv3), un attaquant qui loue une instance sur le même hôte physique que sa cible peut théoriquement exploiter des canaux auxiliaires GPU. En pratique, les hyperviseurs cloud modernes offrent une certaine isolation mais pas une isolation parfaite au niveau hardware. Pour les workloads très sensibles (modèles IA propriétaires, calculs sur données confidentielles), l'utilisation de GPU dédiés (instances "dedicated" ou "bare metal") est recommandée.
Les GPU destinés au jeu vidéo (GeForce) sont-ils moins sûrs que les GPU professionnels (Quadro, Tesla) ?
Dans le contexte des side-channels, la principale différence pertinente est le support du MIG (Multi-Instance GPU) qui n'est disponible que sur les GPU datacenter (A100, H100, A30). Les GPU grand public (RTX 4090, RTX 3080) ne supportent pas l'isolation MIG. Pour les environnements avec des exigences d'isolation forte, seuls les GPU datacenter avec MIG activé offrent les garanties nécessaires.
Télécharger cet article en PDF
Format A4 optimisé pour l'impression et la lecture hors ligne
À propos de l'auteur
Ayi NEDJIMI
Auditeur Senior Cybersécurité & Consultant IA
Expert Judiciaire — Cour d'Appel de Paris
Habilitation Confidentiel Défense
[email protected]
Ayi NEDJIMI est un vétéran de la cybersécurité avec plus de 25 ans d'expérience sur des missions critiques. Ancien développeur Microsoft à Redmond sur le module GINA (Windows NT4) et co-auteur de la version française du guide de sécurité Windows NT4 pour la NSA.
À la tête d'Ayi NEDJIMI Consultants, il réalise des audits Lead Auditor ISO 42001 et ISO 27001, des pentests d'infrastructures critiques, du forensics et des missions de conformité NIS2 / AI Act.
Conférencier international (Europe & US), il a formé plus de 10 000 professionnels.
Domaines d'expertise
Ressources & Outils de l'auteur
Testez vos connaissances
Mini-quiz de certification lié à cet article — propulsé par CertifExpress
Articles connexes
Un projet cybersécurité ? Parlons-en.
Pentest, conformité NIS 2, ISO 27001, audit IA, RSSI externalisé… nos experts répondent sous 24h pour évaluer votre besoin et vous proposer un accompagnement sur mesure.
Commentaires
Aucun commentaire pour le moment. Soyez le premier à commenter !
Laisser un commentaire