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

Il paper "Broken Quantum" presenta il primo audit formale completo dell'ecosistema dei simulatori di calcolo quantistico open-source, rivelando tramite l'analisi statica COBALT QAI e il solver Z3 la presenza di 547 vulnerabilità critiche, inclusa una nuova classe di attacchi di iniezione QASM, e documentando il trasferimento di vulnerabilità da framework commerciali a infrastrutture di laboratori nazionali.

L'essenziale

Broken Quantum: L'Ispezione Segreta dei Motori del Futuro

Immagina che il calcolo quantistico sia come un nuovo tipo di motore per un'auto volante. È rivoluzionario, veloce e promette di risolvere problemi impossibili per le auto di oggi. Tuttavia, prima di poter guidare queste auto nel cielo, gli ingegneri devono costruirle e testarle su un computer normale (classico).

Il documento "Broken Quantum" è come un rapporto di ispezione tecnica condotto da un detective di sicurezza (Dominik Blain) che ha controllato 45 diversi "motori di simulazione" (software) usati dai giganti della tecnologia (IBM, Google, Amazon, Huawei, ecc.) e dalle università più famose del mondo.

Il risultato? La maggior parte di questi motori ha dei buchi enormi nel telaio.

Ecco cosa è stato scoperto, spiegato con metafore semplici:

1. Il Problema Principale: La "Crescita Esplosiva"

Il cuore del problema è una caratteristica fisica dei computer quantistici: più qubit (i "bit" quantistici) aggiungi, più la potenza necessaria raddoppia.

• L'analogia: Immagina di dover copiare una foglia di carta. Se ne hai 1, è facile. Se ne hai 10, è un libro. Se ne hai 50, hai bisogno di 8 petabyte di spazio (più di tutti i dati di Google al mondo!).
• Il bug: Molti software non controllano quanti qubit stai chiedendo. Se un utente (o un hacker) chiede 50 qubit, il software cerca di allocare quella quantità di memoria istantaneamente.
  • Nei computer Python: Il computer esplode di memoria e si spegne (come un motore che si surriscalda e si blocca).
  • Nei computer C++: Il software va in confusione, legge dati sbagliati e può crollare o permettere a qualcuno di prendere il controllo.

2. Le Quattro Categorie di Pericolo (I "Buchi" nel Telaio)

Il report classifica i pericoli in quattro gruppi:

• Classe I: Il "Muro di Mattoni" (C++)

  • Cosa succede: In alcuni software (come quelli di IBM e del Laboratorio Nazionale di Oak Ridge), c'è un errore nel codice che gestisce la memoria. È come se un muratore costruisse un muro di mattoni senza contare quanti ne ha. Se chiedi 64 mattoni, lui ne prende 65, cade nel muro del vicino e distrugge tutto.
  • Il caso speciale: Il laboratorio americano Oak Ridge ha copiato esattamente il codice di IBM (inclusi i difetti) nei loro sistemi. È come se un'agenzia governativa avesse copiato il manuale di istruzioni di un'azienda privata, inclusi gli errori di sicurezza.

• Classe II: Il "Buco Nero" (Python)

  • Cosa succede: Qui il problema è la fame di risorse. Se chiedi al software di simulare un computer quantistico troppo grande, lui cerca di usare tutta la memoria del server.
  • L'attacco: Un hacker può inviare una richiesta con un numero enorme di qubit. Il server cerca di soddisfare la richiesta, si esaurisce la memoria e si spegne. È un attacco di Denial of Service (negazione del servizio): il servizio diventa inutilizzabile per tutti.

• Classe III: La "Bomba a Orologeria" (Deserializzazione)

  • Cosa succede: I software salvano i risultati dei calcoli in file speciali (come file .pkl o .dill). Quando li riaprono, li "decomprimono".
  • Il pericolo: Alcuni software (come quello di Harvard) aprono questi file senza controllare chi li ha scritti. È come se qualcuno ti desse una scatola di regalo e, appena la apri, invece di trovare un dolce, esplode una bomba che prende il controllo del tuo computer.
  • Prova reale: Gli autori hanno creato un file falso che, una volta aperto, ha dimostrato di poter eseguire comandi arbitrari sul computer.

• Classe IV: L'Iniezione "Quantistica" (QASM Injection)

  • Cosa succede: Esiste un linguaggio speciale per i computer quantistici chiamato QASM. È come il linguaggio di programmazione per le auto volanti.
  • Il pericolo: Alcuni software accettano comandi QASM scritti dagli utenti senza pulirli. Un hacker può inserire un comando nascosto che dice: "Prima di volare, ruba i dati del proprietario". È un tipo di attacco che non esiste nel mondo classico, è nuovo e specifico per il quantum.

3. Chi ha fatto bene e chi male?

Il report ha dato un "voto" a ogni software:

• Voto 0/100 (Rotto): IBM (Qiskit), Google (Cirq), Harvard, Tencent, Baidu. Hanno molti buchi critici.
• Voto 100/100 (Sicuro): Alcuni software più piccoli o specializzati (come quelli di ETH Zurich, Oxford, Fujitsu) hanno controllato bene i loro input e non hanno questi difetti. Questo dimostra che è possibile costruire software quantistici sicuri, basta fare attenzione.

4. La Conclusione: Non è un problema di "Futuro", è un problema di "Oggi"

Il messaggio principale è che l'infrastruttura su cui si basa tutta la ricerca quantistica mondiale è fragile.

• Non è colpa della fisica: La fisica quantistica è complessa, ma la sicurezza informatica è una questione di buone pratiche.
• La soluzione: Basta aggiungere un semplice "controllo" all'ingresso del software. Chiedere: "Quanti qubit vuoi? Ok, massimo 50. Se ne chiedi 1000, ti dico di no." Sembra banale, ma nessuno lo stava facendo sistematicamente.

In sintesi:
Il documento "Broken Quantum" ci dice che mentre il mondo corre verso il futuro quantistico, stiamo costruendo le fondamenta su sabbie mobili. Gli autori hanno trovato i buchi, dimostrato come sfruttarli e, soprattutto, hanno mostrato come ripararli. È un invito urgente a tutti i giganti della tecnologia e ai laboratori di ricerca a mettere in sicurezza i loro software prima che qualcuno li usi per fare danni reali.

Sommario tecnico

Titolo: Broken Quantum: Uno Studio di Verifica Formale Sistematica delle Vulnerabilità di Sicurezza nell'Ecosistema dei Simulatori di Calcolo Quantistico Open-Source

1. Il Problema

I simulatori di calcolo quantistico costituiscono l'infrastruttura software classica su cui si basa quasi tutta la ricerca sugli algoritmi quantistici. Nonostante il loro ruolo critico per governi, università e corporation, la sicurezza classica delle loro implementazioni non è mai stata analizzata sistematicamente.
Il problema fondamentale risiede nella natura intrinseca della simulazione quantistica: lo stato di un sistema di $n$ qubit richiede risorse classiche che crescono esponenzialmente ($2^n$). Questa scalabilità esponenziale, se non gestita con validazioni rigorose degli input, crea vulnerabilità di sicurezza che si propagano attraverso l'intero ecosistema software.

2. Metodologia

Lo studio, condotto da Dominik Blain (QreativeLab), ha analizzato 45 framework open-source provenienti da 22 organizzazioni in 12 paesi (inclusi IBM, Google, Amazon, NVIDIA, CERN, Harvard, MIT, ecc.).

La metodologia si basa su COBALT QAI, un motore di analisi statica composto da quattro moduli e supportato dal risolutore Z3 SMT (Satisfiability Modulo Theories):

1. Fase 1 (Scansione Pattern): Utilizzo di espressioni regolari per identificare pattern di vulnerabilità noti (es. allocazioni non validate, deserializzazione insicura) nel codice sorgente.
2. Fase 2 (Verifica Formale): Ogni potenziale vulnerabilità viene codificata come un vincolo di aritmetica a bitvettori. Z3 verifica la raggiungibilità formale della vulnerabilità. Un risultato SAT (Satisfiable) con un "witness" concreto (un valore di input specifico) conferma la vulnerabilità; UNSAT la esclude.
3. Valutazione: Assegnazione di un punteggio di sicurezza (da 0 a 100) basato sulla gravità delle vulnerabilità trovate (CRITICAL, HIGH, MEDIUM).

3. Contributi Chiave

Lo studio presenta i seguenti contributi fondamentali:

• Primo Audit Completo: La più grande analisi di sicurezza formale mai condotta su software quantistico, coprendo 45 framework.
• Tassonomia a Quattro Classi: Identificazione di quattro categorie di vulnerabilità, inclusa una nuova classe specifica per il quantum.
• Dimostrazioni Live (PoC): Realizzazione di proof-of-concept funzionanti per attacchi di Remote Code Execution (RCE) e Denial of Service (DoS).
• Scoperta della Catena di Fornitura: Documentazione del primo caso di trasferimento di vulnerabilità da un framework commerciale (IBM) a un'infrastruttura di laboratorio nazionale USA (Oak Ridge NL) tramite il "vendoring" del codice.
• Verifica Formale: 13 su 13 pattern di vulnerabilità confermati tramite prove di soddisfacibilità Z3.

4. Risultati Tecnici e Classi di Vulnerabilità

L'analisi ha identificato 547 vulnerabilità in totale (40 CRITICAL, 492 HIGH, 15 MEDIUM). Le vulnerabilità sono state classificate in quattro categorie:

Classe I: Corruzione della Memoria in C++ (CWE-125 / CWE-190)

• Contesto: Backend in C++ (es. Qiskit Aer di IBM, XACC di Oak Ridge).
• Meccanismo: Accesso fuori dai limiti degli array (Out-of-Bounds) e overflow di interi.
• Esempio Critico: In Qiskit Aer, l'accesso a un array BITS[64] con num_qubits >= 64 causa un comportamento indefinito. Inoltre, un'operazione di raddoppio dei qubit per le matrici unitarie (2 * n) porta a un overflow quando n=32 (poiché 2*32 = 64, superando il limite a 64 bit).
• Impatto: Corruzione dell'heap, crash del processo o potenziale esecuzione di codice arbitrario.
• Scoperta Supply Chain: Il framework XACC (Laboratorio Nazionale di Oak Ridge) include una copia verbatim del codice vulnerabile di Qiskit Aer, ereditando le stesse 5 vulnerabilità CRITICAL.

Classe II: Esaurimento delle Risorse in Python (CWE-400)

• Contesto: Backend in Python (es. Cirq, PennyLane, qibo, paddle-quantum).
• Meccanismo: Allocazione non validata di array NumPy di dimensioni $2^n$.
• Esempio Critico: Chiamate come np.zeros(2**num_qubits) senza limiti superiori. Un input num_qubits=50 tenta di allocare 8 Petabyte di RAM, causando il termine del processo (OOM Kill) o un DoS remoto negli ambienti cloud.
• Risultato: 167 vulnerabilità HIGH identificate in 14 framework.

Classe III: Deserializzazione Insicura e Iniezione di Codice (CWE-502 / CWE-94)

• Contesto: Serializzazione di circuiti quantistici e oggetti di chimica quantistica.
• Meccanismo: Uso di pickle.load(), dill.load(), eval() o torch.load() su dati non fidati.
• Esempio Critico: Il framework tequila (Harvard) contiene 10 chiamate dirette a pickle.load() per caricare Hamiltoniani e matrici di covarianza. Un file .pkl malevolo può eseguire codice arbitrario (RCE) immediatamente al caricamento.
• Dimostrazione: È stato creato un PoC che esegue codice remoto sfruttando esattamente questo vettore di attacco.

Classe IV: Iniezione QASM (Nuova Classe Specifica per il Quantum)

• Contesto: Parsing di stringhe OpenQASM (il linguaggio assembly quantistico).
• Meccanismo: Iniezione di comandi o definizioni di gate non validati all'interno di stringhe QASM.
• Esempio Critico: API in Qiskit Terra (from_qasm_str, from_qasm_file) e parser in tket (Quantinuum) accettano input utente senza sanificazione, permettendo l'iniezione di gate malevoli o percorsi di file arbitrari (Path Traversal).
• Significato: Questa è una classe di attacco senza analogo classico, specifica dell'infrastruttura quantistica.

5. Risultati di Valutazione e Confini Critici

• Punteggi dei Framework:
  • Broken (0/100): Qiskit Aer, XACC, Cirq, PennyLane, qibo, paddle-quantum, tequila, TensorCircuit, e altri.
  • Secure (100/100): Solo 9 framework sono risultati privi di vulnerabilità (es. qpp, QuEST, qulacs, MindQuantum, Azure QDK). Questi dimostrano che la vulnerabilità è evitabile con una corretta validazione degli input.
• Il Confine dei 32 Qubit: È emerso un confine formale consistente. Sia per gli overflow in C++ che per le allocazioni esponenziali in Python, n=32 è il valore minimo che innesca le condizioni di vulnerabilità critiche (es. 2*32 = 64 bit di overflow, o dimensioni di matrice densità che superano i limiti pratici).
• Distribuzione Istituzionale: Organizzazioni come IBM e Google hanno mostrato framework con punteggi 0/100, mentre altre come Amazon e NVIDIA hanno mostrato migliori pratiche di mitigazione parziale.

6. Significato e Implicazioni

1. Rischio Scientifico e Nazionale: Le vulnerabilità non sono solo bug software, ma minacciano l'integrità della ricerca scientifica e l'infrastruttura dei laboratori nazionali (es. DOE USA).
2. Propagazione della Catena di Fornitura: Il caso XACC dimostra come le vulnerabilità commerciali si propaghino silenziosamente in infrastrutture governative critiche attraverso il riutilizzo del codice (vendoring).
3. Mancanza di Norme: L'ecosistema manca di standard consolidati per la validazione del conteggio dei qubit. 14 team indipendenti hanno implementato lo stesso pattern insicuro (np.zeros(2**n)).
4. Prevenzione Fattibile: La presenza di framework "puliti" (100/100) prova che le vulnerabilità sono prevenibili con semplici controlli agli ingressi delle API (es. limitare num_qubits a 50 per vettori di stato e 25 per matrici di densità).

Conclusione

Il documento "Broken Quantum" evidenzia una crisi di sicurezza sistemica nell'infrastruttura software quantistica. Attraverso l'uso di metodi formali (Z3), lo studio ha dimostrato che l'80% dei framework analizzati è vulnerabile a exploit critici, inclusi RCE e DoS. L'autore ha avviato un processo di divulgazione coordinata con 20 organizzazioni e ha rilasciato gli scanner COBALT QAI per supportare la sicurezza continua dell'ecosistema quantistico.