Cuando se habla de «seguridad y computación cuántica» casi siempre aparece el mismo tema: la criptografía post-cuántica, es decir, cómo blindar los sistemas clásicos —bancos, gobiernos, infraestructura crítica— ante el día en que una computadora cuántica lo suficientemente potente pueda romper el cifrado que hoy usamos. Es un problema real y ya hay estándares (los de NIST) corriendo para resolverlo antes de que sea tarde.
Pero hay una pregunta que casi nadie se hace, y que un grupo de investigadores de la Universidad de Northwestern viene señalando en distintos papers, incluido uno reciente titulado «What is Quantum Computer Security?»: ¿quién protege a las propias computadoras cuánticas de un ataque?
No es una pregunta menor. IBM Quantum, Amazon Braket y Azure Quantum ya ofrecen acceso en la nube a procesadores cuánticos reales. Cualquiera puede mandar un programa (un «circuito cuántico») a esas máquinas. Y ahí es donde empieza el problema: un procesador cuántico en la nube funciona, en la práctica, como cualquier infraestructura multi-usuario —y eso significa superficie de ataque.
La buena noticia: la física ayuda
Hay un principio de la mecánica cuántica que juega a favor de la seguridad: el teorema de no clonación, que dice que es imposible copiar exactamente un estado cuántico desconocido. En términos prácticos, esto elimina de raíz toda una familia de ataques clásicos basados en duplicar contenido de memoria, como ciertas variantes de buffer overflow. Algo que en el mundo del malware tradicional es moneda corriente, en una computadora cuántica simplemente no tiene sentido aplicarlo tal cual.
Ahora la mala noticia: eso no alcanza ni cerca.
Por qué una computadora cuántica es más vulnerable de lo que parece
A diferencia de un procesador clásico, que es básicamente un chip sellado, una computadora cuántica necesita una infraestructura de control clásica gigantesca alrededor: generadores de señales, mezcladores de RF, FPGAs, servidores de gestión, todo coordinado para traducir un programa cuántico en pulsos analógicos precisos sobre el hardware. Esa cadena completa —desde que el usuario escribe el programa hasta que el pulso físico llega al qubit— es, en sí misma, una cadena de eslabones atacables.
Y hay un problema adicional bastante concreto: como las computadoras cuánticas actuales no tienen memoria ni redes cuánticas propias, todo dato tiene que venir incrustado directamente en el programa que se envía a la nube. Constantes, parámetros, información sensible: todo viaja «a la vista» dentro del circuito. Si ese programa se intercepta, se filtra información real, no abstracta.
A esto se suma algo más básico todavía: físicamente, estos sistemas ocupan racks de servidor completos, mucho más accesibles y manipulables que un chip de silicio microscópico. Eso los expone a ataques físicos y de canal lateral que en la computación clásica serían mucho más difíciles de montar.
El catálogo de ataques que ya se documentaron
La investigación en este campo, todavía joven, ya identificó varias familias de amenazas concretas:
- Crosstalk malicioso: en entornos cloud multi-tenant, donde varios usuarios comparten el mismo procesador cuántico, un circuito diseñado a propósito puede degradar la fidelidad de los cálculos de otro usuario que corre «al lado».
- Canales laterales por timing y consumo: analizar cuánto tarda una operación de reset, o medir el consumo eléctrico del hardware, puede revelar qué programa se está ejecutando o incluso permitir reconstruir el circuito a nivel de puertas lógicas.
- Fugas entre ejecuciones: se demostró que las operaciones estándar de «reset» de qubits no siempre borran el estado por completo, dejando filtrarse información de un circuito al siguiente que se ejecuta en el mismo hardware. Es, ni más ni menos, una falla de aislamiento entre procesos.
- Compiladores comprometidos: el compilador que traduce el programa cuántico a instrucciones de hardware es un punto de control enorme. Ya se demostraron ataques (como el llamado QTrojan) capaces de desactivar de forma encubierta la codificación de datos, disfrazando la manipulación como una simple «calibración de pulsos» de rutina.
¿Y las defensas?
La comunidad no se quedó de brazos cruzados. Entre las propuestas más interesantes:
- Entornos de ejecución confiable cuánticos (QTEE), la versión cuántica de lo que en el mundo clásico serían los enclaves seguros.
- PUFs cuánticas (funciones físicas no clonables), usadas para autenticación y verificación de identidad del hardware.
- Huellas digitales de dispositivo y marcas de agua en circuitos, para detectar manipulación o robo de propiedad intelectual.
- Antivirus cuánticos, que usan detección de patrones (isomorfismo de subgrafos) para identificar circuitos maliciosos antes de que corran.
- Split compilation, una técnica que divide un cómputo entre varios proveedores cuánticos distintos para que ninguno tenga la foto completa del programa.
Por qué esto importa ahora, no en diez años
La tentación es pensar «esto es un problema para cuando la computación cuántica sea masiva». El punto que plantea el paper es el opuesto: el momento de diseñar seguridad es mientras la arquitectura todavía se está definiendo, no después. Cloud, multi-tenancy y acceso remoto ya son la norma en computación cuántica hoy, en 2025 —no un escenario futuro—, así que las mismas preguntas que la industria classic-cloud tardó años en resolver (aislamiento, side-channels, integridad del compilador) están sobre la mesa de la computación cuántica desde el día uno.
La criptografía post-cuántica responde «cómo protegernos de las computadoras cuánticas». La seguridad de computadoras cuánticas responde la otra mitad de la ecuación, mucho menos hablada: «cómo protegemos a las computadoras cuánticas mismas». Y a juzgar por lo que ya se descubrió en apenas un par de años de investigación, la lista de vulnerabilidades recién empieza a escribirse.
Basado en: Deshpande, S. y Szefer, J., «What is Quantum Computer Security?», Northwestern University, octubre 2025 (arXiv:2510.07334).