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

O estudo "Broken Quantum" apresenta a primeira auditoria formal de segurança abrangente no ecossistema de simuladores de computação quântica de código aberto, utilizando a ferramenta COBALT QAI para identificar 547 vulnerabilidades críticas e de alto risco, incluindo vetores de ataque específicos da área quântica, em 45 frameworks analisados.

O essencial

Imagine que o mundo da computação quântica é como a construção de um arranha-céu futurista. Antes de colocar o primeiro tijolo real (o hardware quântico físico), os engenheiros precisam desenhar, testar e simular tudo em computadores normais. Esses programas de simulação são os "laboratórios virtuais" onde cientistas do mundo todo (da IBM ao Google, passando por universidades como Harvard e CERN) criam seus experimentos.

O artigo "Broken Quantum" (Quântico Quebrado) é como um relatório de inspeção de segurança de um detetive muito esperto que entrou nesses 45 laboratórios virtuais e descobriu que a maioria deles tem portas abertas, janelas quebradas e fundações instáveis.

Aqui está a explicação do que foi encontrado, usando analogias do dia a dia:

1. O Problema Central: A Escada Infinita

A base de toda a computação quântica é uma regra matemática simples: se você tem n qubits (unidades de informação quântica), o computador precisa calcular 2 elevado a n (2^n) estados possíveis.

• A analogia: Imagine que cada qubit é um degrau em uma escada.
  • 1 qubit = 2 degraus.
  • 10 qubits = 1.024 degraus.
  • 30 qubits = 1 bilhão de degraus.
  • 50 qubits = 1 quadrilhão de degraus (mais do que o número de grãos de areia na Terra).

O problema é que muitos desses programas de simulação perguntam ao usuário: "Quantos degraus você quer?" e, sem verificar se a resposta é possível, começam a construir a escada imediatamente. Se alguém disser "50 degraus", o computador tenta alocar uma quantidade de memória tão grande que ele simplesmente explode (como tentar encher um copo de café com o oceano inteiro).

2. As Quatro "Fissuras" Encontradas

O detetive (o estudo) encontrou quatro tipos principais de falhas:

A. O "Colapso do Prédio" (C++ e Memória)

• Onde: Em programas escritos em C++ (como o Qiskit Aer da IBM e o XACC do Laboratório Nacional de Oak Ridge).
• A Analogia: Imagine um engenheiro que constrói uma parede de tijolos. Ele tem uma lista de tamanhos de tijolos de 0 a 63. Se alguém pede o tijolo número 64, o engenheiro, em vez de dizer "não existe", pega um tijolo aleatório de um depósito vizinho ou tenta usar um número negativo. Isso faz a parede desmoronar ou o prédio inteiro entrar em colapso.
• O Risco: Isso pode fazer o programa travar, corromper dados ou, em casos piores, permitir que um hacker tome o controle do computador (como um ladrão entrando pela janela quebrada).

B. O "Ataque de Exaustão" (Python e Recursos)

• Onde: Em programas escritos em Python (como Cirq do Google, PennyLane da Xanadu, qibo do CERN).
• A Analogia: Imagine um restaurante que aceita pedidos de "quantos pratos você quer?". Se um cliente pede "100 trilhões de pratos", a cozinha tenta preparar tudo de uma vez. A geladeira explode, o chão cede e o restaurante fecha.
• O Risco: Isso não quebra o código, mas consome toda a memória e energia do servidor. É como um ataque de "negação de serviço": o hacker pede uma simulação impossível e deixa o servidor do laboratório ou da nuvem paralisado para todos os outros usuários.

C. O "Envelope Envenenado" (Deserialização Perigosa)

• Onde: Em frameworks como tequila (Harvard) e TensorCircuit (Tencent).
• A Analogia: Imagine que você recebe um pacote pelo correio (um arquivo salvo de uma simulação). O carteiro diz: "Abra e leia o conteúdo". O problema é que, ao abrir, o pacote não contém apenas dados, mas um bilhete que diz: "Execute este comando malicioso no seu computador".
• O Risco: Se um pesquisador baixar um arquivo de simulação de um colega desonesto ou de um servidor comprometido, o simples ato de abrir o arquivo pode infectar todo o computador com um vírus. O estudo mostrou que é possível criar um arquivo falso que, ao ser aberto, executa comandos de controle total (RCE).

D. O "Injetor de Linguagem Quântica" (QASM Injection)

• Onde: Em quase todos os frameworks que aceitam códigos de circuito (como Qiskit Terra e tket).
• A Analogia: Imagine que você está escrevendo uma receita de bolo (o circuito quântico). Alguém injeta uma frase escondida na receita que diz: "Antes de assar o bolo, queime a casa". O programa de simulação lê a receita e, sem pensar, executa a ordem de queimar a casa.
• O Risco: É uma falha única do mundo quântico. Um hacker pode escrever um código de circuito que parece inofensivo, mas esconde instruções para acessar arquivos do sistema ou executar comandos proibidos.

3. A Grande Revelação: O Efeito Dominó (Cadeia de Suprimentos)

Uma das descobertas mais chocantes foi sobre o XACC, um software usado por laboratórios nacionais dos EUA (como o Oak Ridge).

• A Analogia: O laboratório nacional copiou exatamente o manual de instruções de uma empresa comercial (IBM) para usar em seus próprios projetos. Como o manual da IBM tinha um erro de segurança, o laboratório nacional herdou o mesmo erro sem perceber.
• O Impacto: Uma falha em um produto comercial (IBM) se espalhou silenciosamente para a infraestrutura de pesquisa mais segura dos EUA, afetando quatro laboratórios nacionais diferentes.

4. Quem está seguro e quem não está?

O estudo deu uma "nota" para 45 frameworks:

• Nota 0/100 (Quebrados): Grandes nomes como IBM (Qiskit), Google (Cirq), Harvard, CERN e Baidu tiveram notas zeradas em várias categorias. Eles têm falhas críticas.
• Nota 100/100 (Seguros): Alguns frameworks menores ou mais especializados (como qpp da ETH Zurique e QuEST de Oxford) foram impecáveis. Eles provam que é possível construir esses laboratórios virtuais com segurança, basta verificar os números antes de começar a construir.

5. O Que Fazer Agora?

O estudo não é apenas para assustar, mas para ajudar. Eles sugerem regras simples:

1. Verificar o tamanho: Antes de alocar memória, pergunte: "Isso é um número razoável?" (Ex: "Você quer simular 50 qubits? Isso é impossível no seu computador, pare aqui.").
2. Não confiar em arquivos: Nunca abra arquivos de simulação de fontes desconhecidas sem verificar se eles são seguros.
3. Atualizar o código: Os laboratórios que copiaram códigos de outros precisam atualizar suas cópias para corrigir os erros originais.

Conclusão

O mundo da computação quântica está crescendo rápido, mas a segurança dos "laboratórios virtuais" onde tudo é testado foi negligenciada. É como se estivéssemos construindo foguetes para Marte, mas os simuladores de voo usados pelos engenheiros tivessem falhas graves que poderiam explodir o foguete antes mesmo de ele decolar.

O estudo "Broken Quantum" é um alerta urgente: antes de a computação quântica mudar o mundo, precisamos consertar as fundações de segurança onde ela está sendo construída. A boa notícia é que os especialistas sabem como consertar; eles só precisam aplicar as correções agora.

Resumo técnico

Título: Broken Quantum: Um Estudo de Verificação Formal Sistemática de Vulnerabilidades de Segurança no Ecossistema de Simuladores de Computação Quântica de Código Aberto

Autor: Dominik Blain (QreativeLab)
Data: 8 de abril de 2026
Escopo: 45 frameworks de simulação quântica de código aberto de 22 organizações em 12 países.

---

1. O Problema

Os simuladores de computação quântica formam a base de software clássica sobre a qual quase toda a pesquisa de algoritmos quânticos depende. Eles são utilizados por governos, universidades e corporações para desenvolver, validar e testar algoritmos antes de implantá-los em hardware físico.

Apesar de sua importância crítica na infraestrutura científica global, a segurança clássica das implementações desses simuladores nunca foi analisada sistematicamente. O estudo identifica que a natureza exponencial da simulação quântica (onde um estado de $n$ qubits requer $2^n$ recursos clássicos) cria uma superfície de ataque única: qualquer entrada de usuário não validada para o número de qubits pode levar a falhas catastróficas, desde corrupção de memória até negação de serviço e execução remota de código.

2. Metodologia

O estudo utilizou uma ferramenta de análise estática proprietária chamada COBALT QAI, que combina varredura de padrões com verificação formal.

• Ferramenta (COBALT QAI): Um motor de análise estática de quatro módulos apoiado pelo solucionador Z3 SMT (Satisfiability Modulo Theories).
• Fase 1 (Varredura de Padrões): Uso de expressões regulares para identificar padrões de vulnerabilidade conhecidos (CWE) em C++ e Python.
• Fase 2 (Verificação Formal): Cada achado candidato é codificado como uma restrição aritmética de vetores de bits. O solucionador Z3 é usado para provar matematicamente a viabilidade da exploração (SAT) ou a inviabilidade (UNSAT).
• Escopo: Análise de 45 frameworks (incluindo Qiskit, Cirq, PennyLane, XACC, etc.) e uma camada de controle de hardware.
• Métricas de Pontuação: Os frameworks foram classificados de 0 a 100, onde 0 indica "Quebrado" (Broken) e 100 indica "Seguro".

3. Principais Contribuições

1. Primeira Auditoria Abrangente: A maior análise de segurança formal de software quântico até a data, cobrindo 45 frameworks de grandes players (IBM, Google, Amazon, NVIDIA, Baidu, Huawei, CERN, Harvard, etc.).
2. Taxonomia de Quatro Classes de Vulnerabilidade: Identificação de quatro categorias distintas de falhas, incluindo uma nova classe específica de computação quântica.
3. Provas Formais (Z3): 13/13 provas SAT que estabelecem formalmente a alcançabilidade das vulnerabilidades em todos os padrões identificados.
4. Descoberta de Cadeia de Suprimentos: Documentação do primeiro caso de transferência de vulnerabilidade de um framework comercial (IBM) para a infraestrutura de um laboratório nacional dos EUA (Oak Ridge) via vendoring de código.
5. Demonstração de RCE ao Vivo: Prova de conceito (PoC) funcional de Execução Remota de Código (RCE) no framework tequila da Harvard.
6. Ferramentas Abertas: Lançamento dos scanners COBALT QAI para análise contínua.

4. Resultados e Descobertas Técnicas

O estudo identificou 547 vulnerabilidades no total (40 CRÍTICAS, 492 ALTAS, 15 MÉDIAS) distribuídas em quatro classes:

Classe I: Corrupção de Memória em C++ (CWE-125 / CWE-190)

• Alvo: Backends nativos em C++ (Qiskit Aer, XACC).
• Mecanismo: Acesso fora dos limites de arrays e overflow de inteiros.
• Detalhe Técnico: O array BITS[] no Qiskit Aer tem 64 elementos. Quando o número de qubits ($n$) é $\ge 64$, ocorre leitura fora dos limites. Mais crítico: em simuladores de matriz unitária, o número de qubits é dobrado antes da alocação. Um input de $n=32$ resulta em $2n=64$, disparando o acesso BITS[64] (fora dos limites), causando comportamento indefinido e potencial corrupção de heap.
• Impacto: Comportamento indefinido, corrupção de heap e possível execução de código.
• Achado Chave: O framework XACC (Laboratório Nacional de Oak Ridge) incorpora o código C++ do Qiskit Aer verbatim, herdando as mesmas 5 vulnerabilidades críticas.

Classe II: Esgotamento de Recursos em Python (CWE-400)

• Alvo: Backends em Python (Cirq, PennyLane, qibo, paddle-quantum, etc.).
• Mecanismo: Alocação exponencial não validada (np.zeros(2**num_qubits)).
• Detalhe Técnico: Inteiros em Python não estouram, mas a alocação de memória para $2^n$ elementos pode ser massiva.
  • $n=50$: Tenta alocar 8 Petabytes (causando OOM - Out of Memory).
  • $n=40$: Iteração de $10^{12}$ vezes (esgotamento de CPU).
• Impacto: Negação de Serviço (DoS) remota em APIs de nuvem ou travamento de processos locais.
• Estatística: 167 achados ALTOS em 14 frameworks. Frameworks como Cirq, PennyLane e qibo tiveram pontuação 0/100.

Classe III: Desserialização Insegura e Injeção de Código (CWE-502 / CWE-94)

• Alvo: Serialização de circuitos e objetos quânticos.
• Mecanismo: Uso de pickle.load(), dill.load(), eval() e torch.load() sem validação de integridade.
• Achado Crítico (Harvard tequila): 10 chamadas diretas a pickle.load() em um único arquivo para carregar Hamiltonianos e operadores.
• Prova de Conceito: Um arquivo .pkl malicioso de 341 bytes executou código arbitrário imediatamente ao ser carregado, demonstrando RCE completo.
• Outros: Injeção de código via eval() em strings de parâmetros (TensorCircuit, PySCF) e torch.load() sem weights_only=True.

Classe IV: Injeção QASM (CWE-77 / CWE-22) - Nova Classe

• Conceito: Uma classe de ataque específica da computação quântica, sem análogo clássico direto.
• Mecanismo: Dados controlados pelo usuário embutidos em strings OpenQASM atingem os parsers de circuitos sem sanitização.
• Vetores:
  • Injeção via string (ex: definir gates maliciosos ou registradores gigantes).
  • Traversal de caminho via diretivas include em arquivos QASM.
  • Injeção de sub-rotinas em QASM 3.
• Impacto: Qiskit Terra e tket (Quantinuum) expõem pontos de entrada públicos não sanitizados.

A Fronteira de 32 Qubits

O estudo identificou uma fronteira formal consistente em $n=32$.

• Em C++, $n=32$ em simuladores unitários leva a $2n=64$, causando overflow.
• Em Python, $n=32$ para matrizes de densidade ($2^{2n}$) resulta em $2^{64}$, causando overflow de índice ou erro de alocação.
• Isso torna circuitos de 32 qubits (comuns em pesquisa acadêmica) um ponto cego de segurança crítico.

5. Análise de Cadeia de Suprimentos

O estudo mapeou 4 cadeias de propagação de vulnerabilidades:

1. Vendoring: IBM Qiskit Aer $\rightarrow$ XACC (Oak Ridge NL) $\rightarrow$ 4 Laboratórios Nacionais dos EUA.
2. Dependência: OpenFermion (Google) herda vulnerabilidades do Cirq.
3. Replicação Independente: 14 frameworks independentes implementaram o mesmo padrão inseguro de alocação exponencial (np.zeros(2**n)), indicando uma falha sistêmica nas normas de desenvolvimento da comunidade.

6. Significado e Recomendações

Significado:

• Segurança Científica: A integridade da pesquisa quântica global está comprometida. Vulnerabilidades em simuladores podem levar a resultados falsos, roubo de dados de pesquisa ou comprometimento de infraestrutura de HPC.
• Falha Sistêmica: 80% dos frameworks analisados (36 de 45) possuem pelo menos uma vulnerabilidade. Apenas 9 frameworks (como qpp, QuEST, qulacs) foram classificados como "Seguros" (100/100).
• Necessidade de Padrões: A comunidade carece de normas estabelecidas para validação de contagem de qubits.

Recomendações Técnicas:

1. Validação na Entrada da API: Implementar um limite máximo de qubits em todos os pontos de entrada públicos (ex: $n \le 50$ para vetores de estado, $n \le 25$ para matrizes de densidade).
2. Correção de C++: Adicionar verificações de limites estritas antes de acessar arrays como BITS[] e validar o dobro de qubits em simuladores unitários.
3. Substituição de Avisos por Erros: Frameworks como PennyLane devem transformar avisos (warnings.warn) em exceções (ValueError) para impedir alocações perigosas.
4. Atualização de Código Vendido: Laboratórios nacionais devem sincronizar patches de segurança de frameworks comerciais que utilizam código vendored.
5. Desabilitar pickle/eval: Migrar para mecanismos de serialização seguros (ex: torch.load(weights_only=True)) e evitar eval() em strings de entrada.

Conclusão:
O estudo "Broken Quantum" demonstra que a infraestrutura de software clássica que suporta a revolução quântica é fundamentalmente insegura. A correção é tratável (como provado pelos frameworks limpos), mas exige uma intervenção coordenada no nível do ecossistema para estabelecer normas de validação de entrada e melhorar a higiene de segurança na cadeia de suprimentos.