GPU Side-Channels : Attaques sur CUDA, OpenCL et WebGPU

Longtemps réservés au rendu graphique, les GPU (Graphics Processing Units) occupent désormais une place centrale dans l'intelligence artificielle, le calcul scientifique, la cryptographie et jusqu'à l'exécution des navigateurs web. Cette omniprésence élargit considérablement la surface d'attaque. Les GPU side-channels CUDA OpenCL désignent l'ensemble des techniques qui exploitent les fuites d'information involontaires générées par le matériel graphique : caches partagés, compteurs de performance, contention des unités de calcul, consommation électrique ou variations de fréquence. En observant ces signaux, un attaquant peut reconstruire des clés cryptographiques, identifier les pages web consultées par une victime ou dérober les paramètres d'un modèle d'apprentissage automatique. L'arrivée de WebGPU aggrave le risque en rendant ces primitives accessibles depuis du simple code JavaScript, sans installation ni privilège particulier. Cet article détaille les mécanismes de fuite, les scénarios d'exploitation documentés et les contre-mesures applicables.

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 :

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

FAQ — Questions Fréquentes

Conclusion

Ce sujet s'inscrit dans un contexte de menaces en constante évolution. La meilleure protection combine veille active, audits réguliers et sécurité by design. Pour approfondir ou évaluer votre exposition, consultez nos experts.

Besoin d'un expert cybersécurité ?

Audit, pentest, formation, IA — plus de 25 ans d'expérience, 100+ missions réalisées.

Demander un devis [email protected]

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.