Broken Quantum: A Systematic Formal Verification Study of Security Vulnerabilities Across the Open-Source Quantum Computing Simulator Ecosystem

Cette étude présente « Broken Quantum », la première audit formel complet de l'écosystème des simulateurs de calcul quantique open-source, révélant 547 vulnérabilités critiques (dont un vecteur d'attaque QASM inédit) et démontrant, via des preuves de satisfiabilité Z3, des failles systémiques affectant des frameworks majeurs et leur propagation dans l'infrastructure des laboratoires nationaux américains.

L'essentiel

🌌 Broken Quantum : L'Inspection de Sécurité des "Simulateurs Quantiques"

Imaginez que l'informatique quantique est un nouveau type de moteur de voiture capable de rouler à des vitesses impossibles pour les voitures normales. Mais pour l'instant, personne ne possède encore ces voitures réelles. Tout le monde utilise des simulateurs : des logiciels classiques qui imitent le comportement de ces moteurs quantiques sur des ordinateurs normaux.

Ces simulateurs sont la fondation de toute la recherche quantique actuelle. Si le simulateur est cassé, toute la science qui repose dessus est en danger.

L'article "Broken Quantum" est comme un rapport d'inspection technique réalisé par un expert indépendant (Dominik Blain) qui a vérifié 45 simulateurs différents provenant des plus grands géants (IBM, Google, Amazon) et des plus grandes universités (Harvard, MIT, CERN).

Le verdict est sans appel : la majorité de ces simulateurs sont gravement vulnérables.

Voici les 4 principaux problèmes découverts, expliqués avec des analogies simples :

1. Le Problème du "Compteur de Voiture" (Débordement de mémoire)

Le concept : Pour simuler un ordinateur quantique avec n qubits (les pièces de base), l'ordinateur classique doit gérer une quantité de données qui explose : $2^n$.

• 10 qubits = 1 024 données (facile).
• 50 qubits = 1 000 000 000 000 000 000 000 données (impossible à stocker).

L'analogie : Imaginez un parking de voiture. Le logiciel demande : "Combien de voitures voulez-vous garer ?". Si vous répondez "50", le logiciel essaie de construire un parking de la taille de la planète Terre.

• En C++ (le langage rapide) : Le logiciel panique, le compteur dépasse la limite maximale et s'emballe. Il écrit des données n'importe où dans la mémoire, comme si un chauffard conduisait à travers les murs de votre maison. C'est un bug critique qui peut faire planter le système ou permettre à un pirate de prendre le contrôle.
• En Python (le langage flexible) : Le logiciel ne panique pas, il essaie juste de construire ce parking géant. Il épuise toute la mémoire de votre ordinateur (ou du serveur cloud) et le fait s'effondrer. C'est une attaque par épuisement (vous ne pouvez plus rien faire d'autre).

Résultat : 12 frameworks (dont Qiskit d'IBM et Cirq de Google) ont ce problème. Ils sont notés 0/100.

2. La "Boîte à Outils Empoisonnée" (Désérialisation dangereuse)

Le concept : Les chercheurs sauvegardent souvent leurs travaux (leurs circuits quantiques) dans des fichiers pour les rouvrir plus tard. Certains logiciels utilisent un outil appelé pickle pour ouvrir ces fichiers.

L'analogie : Imaginez que vous recevez un colis (un fichier de données) d'un ami. Au lieu de simplement ouvrir le carton, le logiciel dit : "Ah, ce colis contient une note qui dit 'exécute ce code'". Et hop, il exécute le code immédiatement.
Si un pirate envoie un faux fichier "ami" qui contient un virus, le logiciel l'exécute sans poser de questions. C'est comme si votre boîte aux lettres ouvrait la porte de votre maison dès qu'un inconnu glisse un mot dedans.

Résultat : Le framework de Harvard (Tequila) a 10 endroits où ce danger existe. Un pirate peut prendre le contrôle total de l'ordinateur du chercheur.

3. Le "Langage Secret" (Injection QASM)

Le concept : Les ordinateurs quantiques parlent un langage spécial appelé QASM. Les logiciels acceptent des textes en QASM pour créer des circuits.

L'analogie : C'est comme si vous pouviez écrire une lettre à un chef cuisinier (le processeur quantique) pour lui demander de préparer un plat. Mais le logiciel ne vérifie pas ce que vous écrivez.
Un pirate pourrait écrire : "Préparez le plat, et pendant ce temps, brûlez la cuisine". Comme le logiciel ne filtre pas le message, le chef cuisinier obéit et détruit tout. C'est une faille unique au monde quantique, qui n'existe pas dans l'informatique classique.

4. L'Effet "Domino" (La chaîne d'approvisionnement)

Le concept : Les logiciels utilisent souvent du code d'autres logiciels.

L'analogie : Imaginez que le Laboratoire National d'Oak Ridge (un centre de recherche américain ultra-sécurisé) utilise les plans de construction d'IBM pour construire son propre simulateur. IBM a oublié de mettre une serrure sur la porte d'entrée.
Résultat ? Le Laboratoire National a hérité de la même porte sans serrure, même s'ils n'ont pas écrit le code eux-mêmes. C'est ce qu'on appelle le "vendoring" (réutilisation de code). Un bug chez un géant commercial (IBM) se propage silencieusement vers les infrastructures de sécurité nationale.

📊 Le Bilan Global

• 80% des simulateurs testés sont considérés comme "Cassés" (Broken) ou "Exposés".
• Seuls 9 simulateurs sur 45 sont notés 100/100 (sûrs). Ce sont souvent des projets plus petits ou très spécialisés (comme ceux de Fujitsu, Oxford ou ETH Zurich) qui ont pris la peine de vérifier soigneusement les entrées.
• La solution est simple : Il suffit de vérifier le nombre de qubits avant de commencer le calcul. Si quelqu'un demande 50 qubits, le logiciel doit dire "Non, c'est trop grand" au lieu d'essayer de le faire et de planter.

🚨 Pourquoi c'est important ?

Ce rapport ne dit pas que l'informatique quantique est inutile. Il dit que les fondations sont fragiles.

• Les gouvernements, les banques et les laboratoires de médicaments utilisent ces outils.
• Si un pirate peut faire planter un simulateur, il peut bloquer la recherche sur de nouveaux médicaments.
• S'il peut exécuter du code à distance, il peut voler des données sensibles ou corrompre des expériences scientifiques.

L'auteur appelle à une réaction coordonnée : les développeurs doivent ajouter des "gardes-fous" (des vérifications de sécurité) à chaque entrée de leurs logiciels, exactement comme on vérifie l'âge pour entrer dans un club.

En résumé : Nous avons construit des voitures de course quantiques, mais nous avons oublié de mettre des ceintures de sécurité et des freins sur les simulateurs qui nous permettent de les conduire. Il est temps de réparer ça avant que l'accident ne se produise.

Résumé technique

Titre : Broken Quantum : Une étude de vérification formelle systématique des vulnérabilités de sécurité dans l'écosystème des simulateurs de calcul quantique open-source

Auteur : Dominik Blain (QreativeLab)
Date : 8 avril 2026
Sujet : Sécurité informatique, Calcul quantique, Vérification formelle

---

1. Problématique

Les simulateurs de calcul quantique constituent la fondation logicielle classique sur laquelle repose presque toute la recherche en algorithmes quantiques. Malgré leur rôle critique dans l'infrastructure scientifique des gouvernements, des universités et des entreprises mondiales, la sécurité classique de leurs implémentations n'avait jamais fait l'objet d'une analyse systématique.

Le problème racine identifié réside dans une propriété architecturale intrinsèque à la simulation quantique : l'état quantique de $n$ qubits nécessite $2^n$ ressources classiques (amplitudes, probabilités). Cette échelle exponentielle, bien que nécessaire à l'avantage quantique, crée des vulnérabilités graves lorsque le nombre de qubits ($n$) contrôlé par l'utilisateur n'est pas validé avant d'être utilisé pour allouer des ressources.

• En C++, cela entraîne des débordements d'entiers (overflow) silencieux et des accès hors limites (out-of-bounds), menant à un comportement indéfini et à une corruption de la mémoire.
• En Python, cela entraîne une épuisement des ressources (mémoire/CPU) non contrôlé, permettant des attaques par déni de service (DoS).

2. Méthodologie

L'étude présente Broken Quantum, la première audit de sécurité formel complet de l'écosystème des simulateurs quantiques open-source.

• Outil d'analyse : Utilisation de COBALT QAI, un moteur d'analyse statique à quatre modules soutenu par le solveur Z3 SMT (Satisfiability Modulo Theories).
• Portée de l'analyse : 45 frameworks open-source provenant de 22 organisations (IBM, Google, Amazon, NVIDIA, CERN, Harvard, etc.) couvrant 12 pays.
• Processus en deux phases :
  1. Scan de motifs : Détection de motifs de vulnérabilité (expressions régulières) dans le code source (C++ et Python).
  2. Vérification formelle : Chaque découverte potentielle est encodée comme une contrainte d'arithmétique sur les bit-vectors. Le solveur Z3 prouve formellement la réachabilité de la vulnérabilité (résultat SAT) ou son impossibilité (résultat UNSAT).
• Classification : Les vulnérabilités sont classées selon quatre catégories (Classes I à IV) et notées sur une échelle de 0 à 100 (de "Broken" à "Secure").

3. Contributions Clés

1. Premier audit écosystémique complet : Analyse de 45 frameworks, la plus grande étude de sécurité logicielle quantique à ce jour.
2. Taxonomie à quatre classes : Identification de nouvelles vulnérabilités spécifiques au domaine quantique, notamment l'injection QASM.
3. Preuves formelles : 13/13 preuves Z3 SAT validant la réachabilité des motifs de vulnérabilité.
4. Découverte de vulnérabilités par "Vendoring" : Mise en évidence du transfert de vulnérabilités d'un framework commercial (IBM) vers l'infrastructure des laboratoires nationaux américains (Oak Ridge NL) via l'incorporation de code source.
5. Démonstrations de concepts (PoC) : Preuves de concept fonctionnelles pour des attaques RCE (Remote Code Execution) et DoS.
6. Outils ouverts : Publication de COBALT QAI pour une analyse continue.

4. Résultats Techniques

L'étude a identifié 547 vulnérabilités (40 CRITIQUES, 492 ÉLEVÉES, 15 MOYENNES) réparties en quatre classes :

Classe I : Corruption de mémoire en C++ (CWE-125 / CWE-190)

• Cible : Backends C++ (Qiskit Aer, XACC).
• Mécanisme : Accès hors limites (OOB) à des tableaux statiques (ex: BITS[num_qubits]) et débordements d'entiers lors de calculs de taille ($2^n$).
• Cas critique : Dans Qiskit Aer et XACC, un nombre de qubits $n \ge 64$ (ou $n=32$ pour les matrices unitaires doublées) déclenche un comportement indéfini.
• Résultat : 12 findings CRITIQUES. Qiskit Aer et XACC obtiennent un score de 0/100.

Classe II : Épuisement des ressources en Python (CWE-400)

• Cible : Backends Python (Cirq, PennyLane, qibo, etc.).
• Mécanisme : Allocation non validée de tableaux NumPy de taille $2^n$ (ex: np.zeros(2**num_qubits)).
• Impact : Déni de service (DoS) distant ou local. Une requête avec 50 qubits tente d'allouer 8 Pétaoctets de RAM, provoquant un OOM (Out Of Memory) du système d'exploitation.
• Résultat : 167 findings ÉLEVÉS. 14 frameworks touchés, dont Cirq, PennyLane et qibo (tous à 0/100).

Classe III : Désérialisation non sécurisée et Injection de code (CWE-502 / CWE-94)

• Cible : Sérialisation des circuits quantiques (Pickles, Dill, Eval).
• Mécanisme : Utilisation de pickle.load(), dill.load() ou eval() sur des données non fiables.
• Cas critique (Harvard tequila) : 10 appels directs à pickle.load() dans le code de chimie quantique. Un fichier .pkl malveillant permet une Exécution de Code à Distance (RCE) immédiate.
• Autres : eval() dans PySCF (chimie quantique) et torch.load() dans TensorCircuit (Tencent).
• Résultat : Preuve de concept RCE réussie.

Classe IV : Injection QASM (Nouvelle classe spécifique au quantique)

• Concept : Injection de commandes via le langage d'assemblage quantique OpenQASM.
• Mécanisme : Parsing de chaînes QASM non validées (ex: from_qasm_str) permettant l'injection de portes logiques malveillantes ou la traversée de chemins de fichiers (include).
• Cibles : Qiskit Terra (2 points d'entrée non validés), tket (Quantinuum), TensorCircuit.
• Signification : C'est une vulnérabilité sans équivalent classique, spécifique à l'écosystème quantique.

5. Analyse de la Chaîne d'Approvisionnement et Propagation

• Le cas XACC (Oak Ridge National Laboratory) : L'étude révèle que le framework XACC, utilisé par le Département de l'Énergie des États-Unis (DOE), intègre le code source C++ de Qiskit Aer (IBM) en l'état ("verbatim").
• Conséquence : Les 5 vulnérabilités CRITIQUES d'IBM sont héritées silencieusement par l'infrastructure nationale américaine. C'est le premier cas documenté de transfert de vulnérabilité d'un framework commercial vers un laboratoire national via le "vendoring".
• Réplication indépendante : Le motif d'allocation $2^n$ non validé a été répliqué indépendamment dans 14 frameworks différents, indiquant un manque de normes de sécurité dans la communauté.

6. Résultats Quantitatifs et Comparatifs

• État de l'écosystème : 80 % des frameworks (36 sur 45) présentent au moins une vulnérabilité.
• Frameworks "Sûrs" (100/100) : Seuls 9 frameworks sont exempts de défauts (ex: qpp, QuEST, qulacs, MindQuantum, Stim). Ces frameworks démontrent que la validation stricte des entrées (nombre de qubits) suffit à prévenir les vulnérabilités.
• La limite des 32 qubits : Une frontière formelle apparaît à $n=32$. C'est le point où les calculs de matrices unitaires ($2 \times n$) et les densités matricielles ($2^{2n}$) basculent de la plage valide 64 bits vers le débordement ou l'allocation impossible.

7. Signification et Recommandations

• Sécurité Scientifique : La sécurité de ces logiciels n'est pas seulement un problème d'ingénierie, mais une question d'intégrité scientifique. Des vulnérabilités dans les simulateurs peuvent compromettre la recherche en cryptographie, en découverte de médicaments et en optimisation financière.
• Recommandations Universelles :
  1. Validation stricte : Imposer une limite maximale de qubits à chaque point d'entrée de l'API (ex: 50 pour les vecteurs d'état, 25 pour les matrices densité).
  2. Remplacement des avertissements par des erreurs : Convertir les warnings (comme dans PennyLane) en ValueError bloquants.
  3. Gestion du code tiers : Mettre à jour les copies de code "vendored" (comme dans XACC) et synchroniser les correctifs de sécurité.
  4. Sécurisation de la désérialisation : Interdire pickle.load() sur des sources non fiables et utiliser des formats sécurisés.

Conclusion :
L'article "Broken Quantum" démontre que l'infrastructure logicielle du calcul quantique est actuellement fragile face aux attaques classiques. La majorité des frameworks majeurs (IBM, Google, Harvard, CERN) contiennent des failles critiques. Cependant, la vulnérabilité n'est pas inévitable : des frameworks bien conçus prouvent que des correctifs simples (validation des entrées) peuvent sécuriser l'ensemble de l'écosystème. Une action coordonnée au niveau de l'écosystème est nécessaire pour établir des normes de sécurité.