Cerramos la serie donde arrancamos: en el hardware. Pero no en el qubit, sino en todo lo que lo rodea \u2014 la infraestructura de control cl\u00e1sica que, seg\u00fan la investigaci\u00f3n m\u00e1s reciente, resulta ser el punto m\u00e1s f\u00edsicamente vulnerable de toda una computadora cu\u00e1ntica.<\/p>\n\n\n\n
El qubit vive dentro de un criostato de diluci\u00f3n, aislado t\u00e9rmicamente y protegido de interferencias externas con una precisi\u00f3n extrema. Pero los generadores de se\u00f1ales de radiofrecuencia, los mezcladores, los amplificadores y las FPGAs que controlan ese qubit desde afuera no gozan de ese mismo nivel de aislamiento. Viven en racks de servidor convencionales, del mismo tipo que se usa en cualquier centro de datos \u2014 con una diferencia clave respecto a un procesador cl\u00e1sico: mientras que un chip de silicio moderno es del tama\u00f1o de una u\u00f1a y est\u00e1 sellado dentro de una carcasa, la infraestructura de control de una computadora cu\u00e1ntica ocupa habitaciones enteras y es, f\u00edsicamente, mucho m\u00e1s accesible.<\/p>\n\n\n\n
Esa accesibilidad f\u00edsica es, parad\u00f3jicamente, una de las mayores debilidades de la computaci\u00f3n cu\u00e1ntica actual.<\/p>\n\n\n\n
La investigaci\u00f3n en seguridad de hardware cl\u00e1sico lleva d\u00e9cadas estudiando los llamados ataques de canal lateral<\/strong>: t\u00e9cnicas que no rompen un sistema directamente, sino que extraen informaci\u00f3n observando efectos secundarios de su funcionamiento \u2014consumo el\u00e9ctrico, tiempo de ejecuci\u00f3n, emisiones electromagn\u00e9ticas\u2014. La computaci\u00f3n cu\u00e1ntica no es inmune a esto; al contrario, seg\u00fan varios estudios, resulta particularmente expuesta.<\/p>\n\n\n\n Se documentaron casos concretos: el an\u00e1lisis del tiempo que tardan las operaciones de reset entre ejecuciones puede revelar patrones sobre qu\u00e9 programa se est\u00e1 corriendo. El an\u00e1lisis de las trazas de consumo el\u00e9ctrico de los controladores cl\u00e1sicos permite, en algunos casos, hacer ingenier\u00eda inversa de un circuito a nivel de compuertas l\u00f3gicas \u2014 es decir, reconstruir qu\u00e9 algoritmo se ejecut\u00f3 simplemente observando cu\u00e1nta electricidad consumi\u00f3 el sistema mientras lo hac\u00eda.<\/p>\n\n\n\n Quiz\u00e1s el hallazgo m\u00e1s inquietante de los \u00faltimos a\u00f1os en esta \u00e1rea: investigaci\u00f3n espec\u00edfica sobre operaciones de reset en computadoras cu\u00e1nticas NISQ (las de la generaci\u00f3n actual, ruidosas y de escala intermedia) demostr\u00f3 que las compuertas de reset est\u00e1ndar no siempre logran borrar por completo el estado de un qubit entre una ejecuci\u00f3n y la siguiente. El resultado es una filtraci\u00f3n de informaci\u00f3n de un circuito hacia el circuito que se ejecuta despu\u00e9s en el mismo hardware \u2014 una falla de aislamiento entre procesos, en toda regla, muy similar en esp\u00edritu a las vulnerabilidades de aislamiento de memoria que preocupan en la computaci\u00f3n cl\u00e1sica en la nube.<\/p>\n\n\n\n En un entorno multi-tenant \u2014donde varios usuarios distintos comparten el mismo procesador cu\u00e1ntico en la nube, uno despu\u00e9s del otro o incluso simult\u00e1neamente\u2014, esto no es un detalle menor: significa que, en teor\u00eda, el circuito de un usuario podr\u00eda dejar residuos de informaci\u00f3n accesibles para el pr\u00f3ximo usuario que use ese mismo hardware.<\/p>\n\n\n\n Cuando varios usuarios comparten simult\u00e1neamente el mismo procesador cu\u00e1ntico \u2014el modelo de \u00abmulti-programming\u00bb que buscan ofrecer los proveedores cloud para aprovechar mejor el hardware caro y escaso\u2014, aparece otro fen\u00f3meno: el crosstalk<\/strong>. Estudios de caracterizaci\u00f3n de acoplamiento entre qubits permitieron entender con precisi\u00f3n c\u00f3mo un circuito dise\u00f1ado maliciosamente puede degradar deliberadamente la fidelidad de los c\u00e1lculos de otro usuario que corre \u00abal lado\u00bb, en el mismo chip, sin necesidad de acceder directamente a su circuito.<\/p>\n\n\n\n Repasando las tres partes: un programa cu\u00e1ntico pasa por un compilador que puede mentir sobre lo que hace (Parte II), corre sobre hardware de control cl\u00e1sico que puede ser escuchado o interferido desde afuera (esta nota), y todo eso ocurre dentro de una arquitectura completa \u2014desde el programa del usuario hasta la QPU\u2014 donde cada eslab\u00f3n es, potencialmente, un punto de entrada (Parte I).<\/p>\n\n\n\n Esa es la raz\u00f3n de fondo por la que la comunidad de investigaci\u00f3n en seguridad cu\u00e1ntica \u2014Northwestern, Yale, Penn State, y muchos otros grupos que venimos citando en esta secci\u00f3n\u2014 insiste en un mismo mensaje: proteger una computadora cu\u00e1ntica no es un problema de criptograf\u00eda. Es un problema de arquitectura completa, de punta a punta, y reci\u00e9n estamos empezando a entenderlo en profundidad.<\/p>\n\n\n\n Nota publicada: agosto 2026. Tercera y \u00faltima parte de una serie de tres sobre arquitectura de computaci\u00f3n cu\u00e1ntica.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Cerramos la serie donde arrancamos: en el hardware. Pero no en el qubit, sino en todo lo que lo rodea \u2014 la infraestructura de control cl\u00e1sica que, seg\u00fan la investigaci\u00f3n m\u00e1s reciente, resulta ser el punto m\u00e1s f\u00edsicamente vulnerable de toda una computadora cu\u00e1ntica. Lo que el criostato no protege El qubit vive dentro de […]<\/p>\n","protected":false},"author":2,"featured_media":12527,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-12526","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-qc"],"yoast_head":"\nEl problema del reset que no resetea del todo<\/h2>\n\n\n\n
Crosstalk: el ruido de tu vecino de laboratorio<\/h2>\n\n\n\n
El hilo que conecta toda la serie<\/h2>\n\n\n\n
\n\n\n\n